Develop Reference

Basic P2P chat application on the .NET framework

I am attempting to make a chat application on the .NET framework that will be able to communicate over the internet and not just LAN. I would like it to be P2P as to not require a central server. I don't mind which protocol it uses (UDP, TCP, etc) so long as I can send messages to almost any given IP.
All I would like to know is how to send data to another IP I know of, nothing else. I've searched around but the code is too complicated for me. (For example I've looked at the source code for torrent clients).
Help will be appreciated a lot thanks.
P.S.: I've heard about a method called UDP hole-punching if that sparks any plugs.

There is a small issue with your plan.
The server-centric approach does not serve only as a slow middle man, but also as a central point with known address to connect to, an anchor in the sea to attach to and clients connect to the static IP/name of the server.
Usually, users do not care what is their IP address on the internet...
So at the minimum, the server is good to get list of clients.
Nowadays you can use some services from Microsoft or Google or other.
Now rest of the P2P communication of clients between NAT comes with more learning: TCP_hole_punching
I would suggest reading all that stuff then look for some code or library that does it.
Here is older topic similar to yours looking for the hole punching library: tcp hole punching library

I have answered similar kind of things here Peer-to-Peer application using java, let me know if it helps or if you have any specific question about this. Basically you need NAT traversal, so you would find many different ways to achieve this based on your need. Even you can achieve this simply configuring your router by enabling UPnP.

Is it possible that we could communicate C++ program in linux to a C# program acting as server using Remote Method Invocation?

Is it possible to implement client/server communication between a C++ program (client program) running in linux OS with a C# program(server program) running in Windows using RMI implementation?Can anyone suggest any possible way...Any kind of helpful reference is welcome

You would need to go along the lines of Google Protobuf. It is available with C++ and C# as well.
A similar answer from MSDN
It does not matter if you send data from java,c++ or c#, when it goes
over the network it's just 1s and 0s. It's a matter of what you do
with it on the client/server side. So, be sure that the data that you
receive corresponds with the structure that you have (that you want to
deserialize to).
Sometimes you need to manually put the bits and bytes together to get
it all working out. However, there is something called "Protobuff"
that can help you get a common structure of the data that you send,
google it and read all about it.
You can implement client server with sockets and serialize/deserialize it using protobuf.
(MSDN link might help in solution)

I think message passing libraries would fit best in to this. Take a look at ZMQ for instance; they have binding for many languages found here
so you may have your event dispatcher in one language and listener in the other language. Also take a look at apache thrift

CORBA is one IPC mechanism that will provide the RPC mechanism that you are looking for.
Here is a link describing communication between C# server and JAVA client.
http://iiop-net.sourceforge.net/dnAdderRmiClient.html
At one of the companies I worked previously, it was used for communication between c++ and java programs in a client/server model.
They used a combination of ACE/TAO libraries.
http://www.cs.wustl.edu/~schmidt/TAO.html

I would recommend that you do not use remote method invocation for communication between a client and a server. In the nineteen-nineties we used to believe that RMI is a good idea, but since then we have realized that there are much better ways for communication between computers.
The most popular way is by using Web Services, and the easiest flavor of Web Services is RESTful Web Services. (Look them up.) This has the benefit of not caring at all whether the runtime environment of the client looks anything like the runtime environment of the server, as the case is with your setup, where your client is C++ on Linux and your server is C# on Windows.

Mozilla's XPCOM might be your bridge. There is also PyXPCOM. Realistically though the easiest way is to have an intermediate VBox. So you run a VBox instance (running Windows) on the linux machine and then use VBox API (from C++) to issue commands within VBox. So you end up with
Linux <--xpCom--> VBox <--COM--> Windows

When working over network it's protocol what matters, not the client/server.
In telecommunications, a communications protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods.
Source Emphasis is mine.
So, in order to communicate your C++ client and C# server you need to choose or define protocol that will be used for communication.
Your protocol can be build above another protocol. For example, you can use HTTP for transportation purposes and define your protocol describing what syntax should be used for messages in HTTP requests and responses bodies. This will help you, because there're many ready-to-use solutions for HTTP communication.
Actually you will build your protocol based on another anyway. HTTP itself build above TCP. You'll need to choose whether it would be low level or high level protocols. They all have their pros and cons.
But you will have to deal with messaging between your client and server yourself.
As an alternative you can use some Remote Procedure Call(or RPC) solution:
Remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
So that means that you only have to follow guidelines how to build your client and server and all communication will be hidden and will look like as just calling object's method.
Source
Here's short list of possible RPC solutions:
Component Object Model with DCOM. Wiki: COM,DCOM. MSDN: COM, DCOM.
Simple Object Access Protocol. Wiki.
Windows Communication Foundation. Wiki. MSDN. SO(credits to Sanju for link).
To wrap it up:
It's not a problem that your client and server are in different environments and are developed using different platforms. You only have to build communications between them using either your own messaging system based on some protocol, or some RPC system.

We could just write a C# program to listen messages from a particular port and write another C++ client program to write message to that port.As thus we could communicate both application.

Communication between exe?

I have several users on a single Windows Server 2012 (they are using Remote Desktop).
I have two (vb.net) programs, that need to communicate with eachothers - that is ... each user have two applications that need to communicate.
What is the easies (and most realiable) approach to have two apps communicate while several instances is running on the same box (on instance per RDS user)?
Thanks!

There're a lot of options:
Message queue (for, example, MSMQ).
ASP.NET WebAPI self-host
WCF self-host.
...
Maybe, in your case, I would go for the use of message queues. And, since MSMQ comes with Windows (in order to install it, go to Add/remove Windows features in Control Panel) and .NET Framework has support for it out-of-the-box, it could be a good choice.
Side-note
When I mention WCF/WebAPI self-host, I mean that each process can have a very tiny REST or SOAP (or whatever) API that may allow that any of the whole processes may act as clients and/or servers. It's a good way of having interprocess messaging

You can:
1) Use the SendMessage api - http://msdn.microsoft.com/en-gb/library/windows/desktop/ms644950(v=vs.85).aspx
2) Run a client-server http://www.codeproject.com/Articles/12318/Building-Client-Server-applications-with-VB-NET-fo
3) Use UDP broadcasting http://www.solidautomation.com/bryon/Using_UDP_and_Winsock_in_Visual_Basic_6.htm

Available options inter process communication would be:
WCF
Remoting
ASP.Net WebSevices
WM_COPYDATA
Socket programing
Interprocess Communications on MSDN would be resource

Brokerless Messaging C#

I have a number of WPF clients on the same corporate network. I want these clients to share messages with each other. I don't want to run a separate server process so a brokerless solution would seem best. I have considered using PNRP but this seems to require a PNRP service to be running on each client, I'm not sure I could guarantee all the clients would or could be running this. I have also had a look at ZeroMq which looks ideal it terms of simplicity and its very lightweight, however I would need to know the endpoints for a TCP/IP style communication and each client won't be aware of the others rather they need someway to discover each other. So essentially I want a multicast style of communication but without having to use multicast since this will require me to get a range of addresses set up within the corporate network and involve infrastructure etc.
So I guess the question is are there any options I haven't considered that fit the bill?
Thanks in advance for any help.

The ZeroMQ pub-sub pattern is simple and fast until you reach hundreds of clients; you can switch to a real multicast protocol then (PGM) without modifying your application.

Perhaps you should check out NServiceBus. It is a true service bus, so no broker machines in the middle. It runs on MSMQ so your windows servers will support that out of the box. It also supports transactional messaging. It also supports a pub/sub model that should satisfy your multicast requirement.

If you don't mind using a commercial product: OMG's Data Distribution Service is a standard with several implementations that can do what you are looking for. At least one of them supports C# and does not require anything to be installed on your machines -- just the libraries. Disclosure: I work for this company.
So essentially I want a multicast style of communication but without
having to use multicast since this will require me to get a range of
addresses set up within the corporate network and involve
infrastructure etc.
DDS by default uses UDP/IP over multicast for discovery and communication, but can be instructed programmatically or via configuration files to use UDP over unicast only, or TCP. This does not affect application logics, so the conceptual multicast nature is preserved. However, if you do not have IP multicast at your disposal then you will lose some out-of-the-box automatic discovery features. In this case, you would need to know in advance the IP addresses or host names of all nodes that could potentially participate in the communication. From there, the middleware will be able to discover who of these is actually present and adjust its communications accordingly.
I think the latter is true for any solution you choose though. For fully automatic discovery, you will need either multicast/broadcast, or some known discovery server(s) running in your system.

We've written a peer-to-peer message bus, Zebus, based on ZeroMQ (transport), Cassandra (peer discovery and persistence) and Protobuf (serialisation).
It is open source and production tested https://github.com/Abc-Arbitrage/Zebus
Zebus is being actively developed and it is in heavy in-house production use. Currently there is only a .NET language binding but as the OP mentioned that he only had WCF clients this should meet his needs.

Have you considered the peer to peer protocol for WCF? See here for more details: http://msdn.microsoft.com/en-us/library/cc297274.aspx

ZeroMQ is a good choice for this. To solve the discovery problem, stand a server that every client checks in when starting and stopping. This server can also be running ZeroMQ as both a publisher and subscriber.
The clients publish to one port on the server, which binds a subscriber to that port to get check-in and check-out messages. The server in turn publishes those messages on another port (which it also binds) to which the clients subscribe.

Windows Mobile (C#) - Communicating between phone and PC

I'm working on a project where a program running on the mobile phone needs to communicate with a program running on the PC it's connected to. Ideally, I'd like to use USB, WiFi, whatever to communicate.
The two programs should be able to communicate things like battery life, text messages, etc... But I can work on that later, I just need to get them to talk.
What's the best way to do this?

Assuming you have a wifi connection, one way for your Windows Mobile program to communicate with your PC would be to use WCF on the .NET compact framework 3.5.
You'd create a new WCF application to run you your PC, and expose an interface exposing functions you want to call from your Windows Mobile Device.
WCF on Windows Mobile requires Compact Framework 3.5 to be installed on your device.
You also need the "Windows Mobile power toys" to be able to generate compatible proxies to call from Windows mobile.
Power Toys for .NET Compact Framework 3.5
Calling the WCF service from your WM Device also requires you to manually set up the binding and endpoint to pass into your web service proxy (with desktop WCF this is done automatically by loading them from a config file).
WCF on Windows Mobile currently only supports the basic http binding (which can be encrypted if you want), but this may be enough for your needs.

"Best" is really subjective and highly dependent on a lot of factors like devices, topology, firewall presence, need for security, etc, etc.
Where do you need the comms to originate and will you have an ActiveSync connection? If the PC initiates the comms and you have ActiveSync, then RAPI is the transport you'd use as it's got all of the infrastructure done and ready.
For anything else you're going to need some form of proprietary protocol and transport mechanism. Typically I write a simple socket protocol with a defined message structure (typically a message ID, CRC, message length and data payload). I then have some base message class that handles the comms and a set of derived messages for each specific command I want. For 2-way stuff that requires a response, I typically create a base Response class and then derive specific response formats from it.

You might try looking into the OpeNETCF.Desktop.Communications library. You can start at http://www.opennetcf.com/FreeSoftware/tabid/84/Default.aspx and follow the links to find the necessary downloads. (I think you may need to get it from their subversion repository).

WIMO is working on WiFi to desktop support and may be done. Might be worth a look at the code either way.
home
source

found this in 2015, so I don't think the answer is going to be relevant for the original asker, but for the record:
Proximity
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465205.aspx