Develop Reference

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.

can we sniff some program's network traffic?

I want to develop a program in c# that can target and application or port's traffic and tries to view that traffic.For example,I select example.exe program in my application and it gives me it's network traffic data.
Is it possible?If so,give me some directions.
I'm trying not to use airPcap or winPcap or anything like these,because these libraries target the network card and I don't know what type of interface card the user might be using.

You have to either capture packets where you receive a duplicate from the NIC (pcap), or route requests through your own application so you can inspect the live packet flow (proxy-like).
For a WinPcap implementation in C#, take a look at SharpPcap. For a proxy, see here.

winPcap is a very good library for what you want to do.
If you choose to do it yourself, you will only be reinventing the wheel, and might not be able to support as many network cards as it does.
If you only want to see the traffic, you would have to use a proxy in between.
But I believe you are not looking to build something like, fiddler for example,
that sits in between and allows you to monitor the traffic.

If I understand you correctly you want make a c# app where you select from a list of running applications and display the network traffic to/from that app. You could do this with c# but you would have to make calls to the Windows API to get the information you need. In addition you will need non-c# library for packet capture sucgh as WinPcap. Windows has a new NetMon API that does pcap like things. I have not used it, but you probably way better off with pcap and the SharpPcap lib that CodeCaster posted.

C#, WCF, want to make a chat application, what binding should I use? maybe some examples?

I am looking forward to make a sort of a chat application using C# and WCF, yet before I start I wanted to clear a few things, so that I don't get carried in the wrong direction. :)
the application should be able to both make event ( send messages ) and listen to events ( receive messages ), therefor if I understand it right, the application should be both the client and the server at once?
what binding should I use? If I understand right, basicHttp binding hard to configure and is used when a WCF app needs to connect to non-WCF app? While for connecting two WCF apps its better to use NetTcpBinding?
how would this applications find each other, considering that they are running on different machines? should there be a central server, to which the app would connect first, saying "I'm user123, my IP is that and that, I'm free for chat" and look for other user IP addresses there? Or is there some other ways for apps to find each other without the central server?
maybe you could direct me to some examples or tutorials on this topic? ( tried googling, no luck ).
Thanks! :)

If your peers (machine that can operate as a client & server) are going to be behind NATs/firewalls then you will have a very very tough time building a chat application using WCF. If the peers will all be on the same network WCF is workable.
To write a chat application from scratch using WCF you will be re-inventing the wheel. Why not employ an existing protocol that's been designed precisely for the purpose such as XMPP. There are XMPP libraries around for .Net. You will need a central server but if you use XMPP you could feasibly piggyback onto one of the many existing free servers.

You can use netPeerTcpBinding.
See also:
http://blogs.interknowlogy.com/2009/08/05/building-a-really-simple-wcf-p2p-application/
http://msdn.microsoft.com/en-us/library/bb690929(v=vs.90).aspx
http://www.codeproject.com/KB/WCF/Chat_application_using_WC.aspx

There is no right and wrong answer to your question - it all depends on what you require. You then can choose the best architecture for your needs, and then the best technology for that architecture.
There are two things to consider - how will users find people to chat to, and then once they have found someone - how do the applications connect to each other.
For users to find each other, you either need to connect to a central server, which will then show a list of all connected users, or users need to enter the IP address of the person they want to chat to. Note that some firewalls will block incoming connections in this second case, so this may not be feasible in some cases.
Next, once you have found the person you wish to chat to, you need to decide whether messages will route directly to the other user, or if you want to continue to go through a central server.
If you choose to go through a central server, then your application will be functioning as a client, and will therefore pass through firewalls without a problem. However if you connect directly to the other user, both copies of the application will be acting as a client and a server (P2P topology), and therefore firewalls may be an issue. Having said that, you could designate one of the applications to be a server, with the other acting as a client, in which case only the server side needs to worry about the firewall.
Without knowing exactly what you are trying to achieve, it is hard to recommend which architecture will work best for you.

Communication between two separate applications

I have developed a windows service which reads data from a database, the database is populated via a ASP.net MVC application.
I have a requirement to make the service re-load the data in memory by issuing a select query to the database. This re-load will be triggered by the web app. I have thought of a few ways to accomplish this e.g. Remoting, MSMQ, or simply making the service listen on a socket for the reload command.
I am just looking for suggestions as to what would be the best approach to this.

How reliable does the notification has to be? If a notification is lost (lets say the communication pipe has a hickup in a router and drops the socket), will the world end come or is business as usual? If the service is down, do notifications from the web site ned to be queued up for when it starts up, or they can e safely dropped?
The more reliable you need it to be, the more you have to go toward a queued solution (MSMQ). If reliability is not an issue, then you can choose from the mirirad of non-queued solutions (remoting, TCP, UDP broadcast, HTTP call etc).
Do you care at all about security? Do you fear an attacker my ping your 'refresh' to death, causing at least a DoS if not worse? Do you want to authenticate the web site making the 'refresh' call? Do you need privacy of the notifications (ie. encryption)? UDP is more difficult to secure (no session).
Does the solution has to allow for easy deployment, configuration and management on the field (ie. is a standalone, packaged, product) or is a one time deployment that can be fixed 'just-in-time' if something changes?
Withous knowing the details of all these factors, is dififcult to say 'use X'. At least one thing is sure: remoting is sort of obsolete by now.
My recommendation would be to use WCF, because of the ease of changing bindings on-the-fly, so you can test various configurations (TCP, net pipe, http) w/o any code change.
BTW, have you considered using Query Notifications to detect data changes, instead of active notifications from the web site? I reckon this is a shot in the dark, but equivalent active cache support exists on many databases.

Simply host a WCF service inside the Windows Service. You can use netTcpBinding for the binding, which will use binary over TCP/IP. This will be much simpler than sockets, yet easier to develop and maintain.

I'd use standard TCP sockets - this will survive all sorts of moving of components, and minimize configuration issues IMHO.

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