Menu
How efficient is it to use sockets when doing IPC as compared to named pipes and other methods on Windows and Linux?
Right now, I have 4 separate apps on 4 separate boxes that need to communicate. Two are .NET 3.5 applications running on Windows Server 2003 R2. Two are Linux (Suse Linux 10). They're not generally CPU bound. The amount of traffic is not that large but its very important that it be low latency. We're using sockets right now with nagle dis-abled and the sles10 slow start patch installed on the linux machines.
How much of a speed boost do you think we would get by simply running the two windows apps on the same windows box and the two linux apps on the same linux box and making no code changes (ie still using sockets).
Will the OS's realize that the endpoints are on the same machine and know not to go out to the ethernet with the packets? Will they packets still have to go through the whole networking stack? How much faster it be if we took the time to change to named pipes or memory mapped files or something else?
695
This means that on Linux and macOS, you can generally use all of the general purpose file functions with socket handles (e.g. read() , write() ). On Windows, socket handles can only be used with special socket functions.
It's available by default on macOS, Linux, and Windows. Local Address is *.65432 , which means all available host interfaces that support the address family will be used to accept incoming connections. In this example, socket.AF_INET was used (IPv4) in the call to socket() .
Sockets allow communication between two different processes on the same or different machines. To be more precise, it's a way to talk to other computers using standard Unix file descriptors. In Unix, every I/O action is done by writing or reading a file descriptor.
The setsockopt function sets the current value for a socket option associated with a socket of any type, in any state. Although options can exist at multiple protocol levels, they are always present at the uppermost socket level.
As for TCP performance, I have done this sort of test recently on an HP-UX server (8 Intel Itanium 2 processors 1.5 GHz 6 MB, 400 MT/s bus) and on Red Hat Linux (2 IA-64 1,6 Ghz). I used iperf in order to test TCP performance. I found that speed of TCP exchange is more than ten times faster when I run iperf on the same machine comparing to running iperf on two different machines.
You can also give it a try as there are options that might be of interest to you - length of buffer to read or write, set TCP no delay and so on. Also you can compare speed of TCP exchange on Windows machines as there is a version of iperf for Winddws.
This is a more detailed comparison:
1) Speed of TCP exchange between two iperf applicatons running on different HP-UX server, default TCP window 32K: 387 Mbits/sec
2) Speed of TCP exchange between two iperf applicatons running on different HP-UX server, TCP window 512K: 640 Mbits/sec
3) Speed of TCP exchange between two iperf applicatons running on the same HP-UX server, default TCP window 32K: 5.60 Gbits/sec
4) Speed of TCP exchange between two iperf applicatons running on the same HP-UX server, default TCP window 512K: 5.70 Gbits/sec.
5) Speed of TCP exchange between two iperf applicatons running on the same Linux server, TCP window 512K: 7.06 Gbits/sec
6) Speed of TCP exchange between two iperf applicatons running on HP-UX and Linux, TCP window 512K: 699 Mbits/sec
77
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
