Printable View
Is it possible to use sockets (winsock2, not MFC) to communicate between two processes running on the same computer?
If so, could someone give me a very simple example (for example, "program1.exe" sending the message "Hello" to "program2.exe" and "program2.exe" receiving that message, where "program1.exe" and "program2.exe" are processes running on the same computer)?
Thank you in advance,
HighCommander4
There are better ways to communicate with other processes on same computer, like sending messages, using shared memory, mailslots.
Here is the link to samples & articles on Interprocess communication,
http://www.codeproject.com/threads/#...+Communication
Using sockets is not a problem but they are not exactly meant for communication on local computer.
Hi,
SURE you can use it for IPC (interprocess communication), but it is not meant for that. so its better to some other thing which meant for IPC like pipes, shared memory,signaling, send messages etc.
And about using sockets for IPC, it just like any other client server program. In simple, the two programs will be client and server running on the same machine and note that when you make one program as server to accept messages from other program, it becomes potential threat for your computer.
bye
P.Somasundaram
definitely possible
check out msdn
socket is not the best solution for ipc because of network security and hardware dependency
Kuphryn
As kuphryn has indicated, sockets are not the sole form of interprocess communication (IPC) provided in the Windows OS.
See "Interprocess Communications" at http://windowssdk.msdn.microsoft.com.../ms690478.aspx , which serves as a jumping-off point for describing the following IPC mechanisms:
Clipboard
COM
Data Copy (i.e., WM_COPYDATA)
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets
Sockets has one advantage: if you ever want to deploy your app across different machines, then the architecture is alreay in place.
Incidentally, I don't think there's a hardware dependency when using sockets at the loopback address on the same machine. It's my understanding that if the Winsock stack detects the loopback address, then the data never even appears on the network wire, and it's purely software that routes the data back into the bottom of the Winsock stack.
Mike
Well, the hardware does need to be present, so there is that dependency. I don't believe you can install "Networking" without a network card.
Viggy
Quote:
Originally Posted by MrViggy
Actually you can force windows to install TCP/IP without the network card, but still the TCP/IP is dependancy.
Ahh, I was not aware of that. It's been a while since I had a machine that did not have a network card. :)Quote:
Originally Posted by Krishnaa
Viggy
Almost nobody (not at least from developers) have system without network card today. How can they survive without internet ? :pQuote:
Originally Posted by MrViggy
Thank you all for the advice, I have decided to use named pipes for inter-process communication instead.
I just have one question about using named pipes:
When a process is reading from a pipe using ReadFile() or making a transaction using TransactNamedPipe(), is there a way to have these functions time out after a certain amount of time (similarly to the way WaitNamedPipe() has a time-out feature), as opposed to the functions running indefinitely until a message from the process at the other end arrives?
I am worried that a situation could arise where the process at one end crashes, or gets stuck in an infinite loop, or encounters some other error that prevents its from sending a message, and the other process, which is expecting a message, gets stuck with a ReadFile() or TransactNamedPipe() operation that never returns...
I think the pipe functions return error when other side crashes/closes, without hanging forever.
What about if the other side does not close, it just gets stuck in an infinite loop or something?Quote:
Originally Posted by Krishnaa
Also, I have another question... when you use WriteFile(), what happens when you send a message greater than the specified output buffer size? Will the message still get through and when the other side calls ReadFile() it will return ERROR_MORE_DATA and they can read the whole message using additional calls to ReadFile()? Or will a buffer overflow/some other problem occur?
EDIT: One more question... is there a way to check if a pipe with a certain name exists (without actually connecting to it)? It was trying to use GetNamedPipeInfo() but I realized that it needs a pipe handle (as opposed to a pipe name) as its argument... (EDIT2: the best thing I can think of is to connect and then disconnect immediately, but what if the server has only created the pipe, and is not calling ConnectNamedPipe() at the time?)