What's the difference between streams and datagrams in network programming?

Question

What's the difference between sockets (stream) and sockets (datagrams)?

Why use one over the other?

Freiman

Answer 1

A long time ago I read a great analogy for explaining the difference between the two. I don't remember where I read it so unfortunately I can't credit the author for the idea, but I've also added a lot of my own knowledge to the core analogy anyway. So here goes:

A stream socket is like a phone call -- one side places the call, the other answers, you say hello to each other (SYN/ACK in TCP), and then you exchange information. Once you are done, you say goodbye (FIN/ACK in TCP). If one side doesn't hear a goodbye, they will usually call the other back since this is an unexpected event; usually the client will reconnect to the server. There is a guarantee that data will not arrive in a different order than you sent it, and there is a reasonable guarantee that data will not be damaged.

A datagram socket is like passing a note in class. Consider the case where you are not directly next to the person you are passing the note to; the note will travel from person to person. It may not reach its destination, and it may be modified by the time it gets there. If you pass two notes to the same person, they may arrive in an order you didn't intend, since the route the notes take through the classroom may not be the same, one person might not pass a note as fast as another, etc.

So you use a stream socket when having information in order and intact is important. File transfer protocols are a good example here. You don't want to download some file with its contents randomly shuffled around and damaged!

You'd use a datagram socket when order is less important than timely delivery (think VoIP or game protocols), when you don't want the higher overhead of a stream (this is why DNS is primarily a datagram protocol, so that servers can respond to many, many requests at once very quickly), or when you don't care too much if the data ever reaches its destination.

To expand on the VoIP/game case, such protocols include their own data-ordering mechanism. But if one packet is damaged or lost, you don't want to wait on the stream protocol (usually TCP) to issue a re-send request -- you need to recover quickly. TCP can take up to some number of minutes to recover, and for realtime protocols like gaming or VoIP even three seconds may be unacceptable! Using a datagram protocol like UDP allows the software to recover from such an event extremely quickly, by simply ignoring the lost data or re-requesting it sooner than TCP would.

VoIP is a good candidate for simply ignoring the lost data -- one party would just hear a short gap, similar to what happens when talking to someone on a cell phone when they have poor reception. Gaming protocols are often a little more complex, but the actions taken will usually be to either ignore the missing data (if subsequently-received data supercedes the data that was lost), re-request the missing data, or request a complete state update to ensure that the client's state is in sync with the server's.

Billow

Simply superb for including the detail of SYNACK. – Exenterate

This example, or a very similar one, is from The Linux Programming Interface. The 2010 edition contains these examples on pages 1155 and 1159. – Mummy

Answer 2

Stream Socket:

• Dedicated & end-to-end channel between server and client.
• Use TCP protocol for data transmission.
• Reliable and Lossless.
• Data sent/received in the similar order.
• Long time for recovering lost/mistaken data

Datagram Socket:

• Not dedicated & end-to-end channel between server and client.
• Use UDP for data transmission.
• Not 100% reliable and may lose data.
• Data sent/received order might not be the same.
• Don't care or rapid recovering lost/mistaken data.

Forest

Isn't data sent in the same order (not just "similar")? ie. it wouldn't make sense to build a packet ordering mechanism into a stream socket – Mcleroy

Packets in a stream communication are sent and received in "similar" order in the sense that the packets themselves are NOT guaranteed to be delivered to the receiving host in order, but TCP figures out the discrepancies, rearranging the packets as they arrive and requesting anything that seems to have gotten lost along the way. – Forest

That makes sense. Maybe just remove that as a difference then and put it beneath (since if I'm understanding it correctly, when referring to only the order at which the packets are sent, in both cases the order that the data is sent/received might not be the same). – Mcleroy

@Rick More precisely, sockets are known as end-to-end points because transport protocols are responsible for delivering messages to one or multiple network endpoints. – Forest

Answer 3

If it is the network programming I think starting from sockets would be a good start.
socket = ip + port
there are three types of sockets
stream (TCP, order and delivery guaranteed,no duplication,no length or char boundaries for data,connection-oriented,reliable, concurrency)
datagram(UDP,packet-based, connectionless, datagram size limit, data can be lost or duplicated, order not guaranteed,not reliable)
raw (direct access to lower layer protocols IP,ICMP)
I do not see any strict rule for transport protocol type as to what socket has to use what transport protocol and reliability should not be mistaken because UDP is realiable in case both ends are active.
Reliability refers to more like reliability of delivery since there are sequence number checks by using TCP as transport protocol which do not exist in UDP.It is better using network protocol analyzer like wireshark tcpdump etc to see what your software is exactly doing; kind of verification or merging theory on the paper with your work in action.

Swinson