Difference between UNIX domain STREAM and DATAGRAM

2019-03-07 23:12发布

问题:

This question is NOT for the difference between STREAM type and DATAGRAM type INTERNET sockets. I know that STREAM sockets use TCP, Datagram sockets use UDP and all the TCP,UDP stuff, packets arriving in order, ACK, NACK etc. I understand the importance of these over internet.

Q1) When I create a UNIX domain socket which is a local socket, how would it matter if the socket is STREAM socket or DATAGRAM socket. This type of socket would write the data to the socket file, would the protocol matter in this case since I am not transmitting data over a network? Is there any chance of data loss in this case if I use UNIX-based DATAGRAM sockets?

Q2) Does UNIX DATAGRAM sockets provide better performance than UNIX STREAM sockets?

Q3) How to decide for a STREAM/DATAGRAM UNIX based socket in my application?


Thanks

回答1:

Just as the manual page says Unix sockets are always reliable. The difference between SOCK_STREAM and SOCK_DGRAM is in the semantics of consuming data out of the socket.

Stream socket allows for reading arbitrary number of bytes, but still preserving byte sequence. In other words, a sender might write 4K of data to the socket, and the receiver can consume that data byte by byte. The other way around is true too - sender can write several small messages to the socket that the receiver can consume in one read. Stream socket does not preserve message boundaries.

Datagram socket, on the other hand, does preserve these boundaries - one write by the sender always corresponds to one read by the receiver (even if receiver's buffer given to read(2) or recv(2) is smaller then that message).

So if your application protocol has small messages with known upper bound on message size you are better off with SOCK_DGRAM since that's easier to manage.

If your protocol calls for arbitrary long message payloads, or is just an unstructured stream (like raw audio or something), then pick SOCK_STREAM and do the required buffering.

Performance should be the same since both types just go through local in-kernel memory, just the buffer management is different.



回答2:

The main difference is that one is connection based (STREAM) and the other is connection-less (DGRAM) - the difference between stream and packet oriented communication is usually much less important.

With SOCK_STREAM you still get all the connection handling, i.e. listen/accept and you can tell if a connection is closed by the other side.

Note that there is also a SEQPACKET socket type that's still connection oriented, but preserves message boundaries (which might save you from implementing a message-oriented layer on top of a STREAM socket).

I would expect data transfer performance to be similar for all of these types, the main difference is just what semantics you want.



回答3:

  1. One likely difference are message boundaries. Datagrams will be delivered as a whole with the datagrams being the natural message boundaries. With stream sockets you can read N bytes and the socket will block until N bytes are ready. But this means no obvious message boundaries.
  2. Maybe. A stream socket with TCP at least needs the initial three way handshake to establish the connection. A UDP socket does not.
  3. All things being equal, if speed is a concern, instrument and measure. (I assume you already know that only a TCP stream socket provides built-in reliable in-order transport, and only datagram sockets can be used to send to multiple receivers).


回答4:

If the clients and servers will always be on the same machine and the goal is to have minimal latency and maximum bandwidth, use shared memory.