aureliuh
asked on
IPC through socketc in windows
Hello,
Is there any method to implement an IPC with sockets on Windows but the connection between server and client to be invisible with netstat ?
Thank you very much
Is there any method to implement an IPC with sockets on Windows but the connection between server and client to be invisible with netstat ?
Thank you very much
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
jkr
Any socket communication will be visible via netstat - and that is good the way it is. Otherwise malware could communicate without the risk of being detected. Why do you want to hide your communication?
ASKER
Ok... I understand that iot is a good thing to see those connections, but I am not interested in a connection with the outside (Lan, internet)
I want to make a client and a server and use only the loopback interface. So this is the reasson that I thaught it could be possible
I want to make a client and a server and use only the loopback interface. So this is the reasson that I thaught it could be possible
If it is only local anyway, why would you want to hide the connection?
ASKER
If user will run netstat -a , he will see a bunch of terminated connections.
If you want something that your user won't see, use Named Pipes (http://www.codeproject.com/threads/NamedPipesTracing.asp or http://www.codeproject.com/threads/connectionpipe.asp), Shared Memory (http://www.codeproject.com/threads/sharedmemipc.asp) or any other technique described at http://www.codeproject.com/threads/ipcworkshop.asp
jkr is right. If you need a p2p communication locally only, sockets is not the only choice - maybe not even the preferred one.
I would go for shared memory if the amount of data transferred at a given time slot can be limited. E. g. you could make a little class which creates or opens a fixed size piece of shared memory (create for first access, open for second) and provides a multi-process-safe queue management for two queues, one for the server and one for the client. The synchronization can be achieved by means of a named mutex object or by a hand-made synchronization similar to traffic lights. The interface would work similar to a non-blocking socket, so that each side easily could check for incoming messages and make a safe read on the own queue and a safe write to the other side's queue.
Regards, Alex
I would go for shared memory if the amount of data transferred at a given time slot can be limited. E. g. you could make a little class which creates or opens a fixed size piece of shared memory (create for first access, open for second) and provides a multi-process-safe queue management for two queues, one for the server and one for the client. The synchronization can be achieved by means of a named mutex object or by a hand-made synchronization similar to traffic lights. The interface would work similar to a non-blocking socket, so that each side easily could check for incoming messages and make a safe read on the own queue and a safe write to the other side's queue.
Regards, Alex