Some summaries of Unix domain sockets

by fireworks2@foxmail.com

Looking for more than half of the day's data, harvest is not much, in fact, or their own thinking more reliable.

1. Data Reporting Services for UNIX domains are reliable

The man UNIX manual will see that the data for UNIX domain sockets is neither lost nor disorderly (as far as I know, it is true under Linux). However, the latest version of the kernel still provides a guaranteed order of type "kernel 2.6.4 sock_seqpacket ".

2. The main differences between STREAM and Dgram

Since the datagram is not lost and reliable, it is not like the STREAM is very similar. I understand and I do, and I think Dgram is a little bit better because the data can be sent with boundaries. The other difference is the amount of data sent and received, based on the STREAM socket, send can pass over so_sndbuf Long data, recv with TCP similar to the existence of data adhesion.

Use the API in blocking mode, blocking if the buffer queue is full when the UNIX domain socket is lowered with sendto. and UDP because is not reliable, unable to perceive on the end of the situation, even if the end did not collect data in time, basically SendTo can immediately return success (if the originator of crazy SendTo is another matter, because too fast to call SendTo in the slow network environment, may burst the socket buffer, Cause sendto blocking).

3. So_sndbuf and So_revbuf

For UNIX domain sockets, setting SO_SNDBUF affects the maximum message length of sendto, but any settings for SO_RCVBUF are not valid. In fact, the data of UNIX domain socket is to put the data into the kernel of the application of the memory block, and then another process through the recvfrom from the kernel, so the specific length of the datagram can be sent by the kernel slab strategy. Under the Linux platform, previous versions (such as 2.6.2) could send the maximum datagram length of approximately 128 K, and the new version of the kernel would support a larger length.

4. The length of the buffer queue when using Dgram

There are several factors that affect the length of the buffer queue, one is the slab policy mentioned above, and the other is the kernel parameter/proc/sys/net/unix/max_dgram_qlen of the system. The length of the buffer queue is a common decision.

If Max_dgram_qlen defaults to 10, when the datagram is small (such as 1k), first suspend the process of receiving data, can still sendto 10 times and smooth return;

But if the data is large (such as 120k), it is necessary to see slab "size-131072" limit.

5. Using UNIX domain sockets for interprocess communication vs. other ways

· Need to determine the operating system type, and its corresponding maximum dgram length, if there is a need to transfer more than the length of the datagram, it is proposed to split into several sent, received after the assembly can be (do not disorderly order, the individual feel that this is more convenient than using the STREAM to cut the package more easily

· In contrast to pipelines, UNIX-domain datagrams not only maintain data boundaries, but also do not encounter atomicity problems when writing to pipelines.

· Compared to shared memory, it is not possible to cache large amounts of data independently of the process, but avoids the consideration of synchronous mutexes.

· Compared with ordinary sockets, the overhead is relatively small (without calculating headers), the Dgram message length can be greater than 64k, but not the same as normal socket to switch processes to different machines.

6. Other

In fact, when the native IPC compared with the normal socket of UDP, UNIX domain socket data is only in the receiving and dispatching of less than a checksum, this machine UDP will go Lo interface, will not be IP fragmentation, and will not really run to the network card link layer up (not Will consume the NIC hardware). In other words, the use of ordinary socket UDP on this machine, but more consumption of some CPU (the reason for some, because the calculation of the checksum is very simple), in addition to the machine's UDP can ensure that the data is not lost, not disorderly order.

From my personal experience, even the high concurrency of the network server, simply because of the CPU consumption caused by the package is actually not much (of which the CPU taken up from the%si can be seen, because the packet needs to be implemented through soft interrupt), but the network card bandwidth, disk IO, background logic, Problems such as memory usage often become principal contradictions.

Therefore, when there is no long time to cache the requirements of the communication data, we can consider the implementation of the local IPC through UDP, so that it is also easy to switch machines. (also do not have to worry about the maximum length of the UNIX domain socket datagram, hehe) for a longer message, you can cut into small, and then reassemble, but this only applies to native communication, if you want to consider the migration after the machine, it is still honest TCP bar. (Local TCP consumption of resources is not known, did not do enough testing, but local TCP own some of the contract operation does not constitute a bottleneck)

---Other resources found at Google are listed here as well---

SetSockOpt the redundancy allocation when SO_SNDBUF SO_RCVBUF is set:

http://www.tux.org/lkml/

Use of UNIX domain sockets:

Http://www.cnblogs.com/skynet/archive/2010/12/04/1881236.html

Http://hi.baidu.com/studyarea/blog/item/b007f4450a2a9e38879473ca.html