Networking: Datagrams, Transactions, Streams

Networking: Datagrams, Transactions, Streams

Home

There are four ways to send data to remote hosts:

Datagram: Very fast but unreliable data packet to another host.
Broadcast: Very fast but unreliable data packet to one or many hosts.
Transaction: Simple and atomic data exchange between two hosts.
Stream: Orderly and reliable data exchange between two hosts.

Datagram protocols, such as IP, UDP, or DDP, are the simplest to use, and all other network protocols are layered on top of them. A packets of data is sent from one host to another, and then passed to higher protocols for post-processing, or to the application itself.

Broadcasts and multicasts are basically datagrams that are sent to special network addresses. The packets are routed to one or more hosts at the same time, reducing overall network traffic.

Transaction protocols, such as ATP, are composed of sequenced datagrams, often called "requests" and "responses." A request packet is sent repeatedly to a remote host until he receives and acknowledges it by sending a response, adding simple reliablility to datagram protocols.

Stream protocols, such as TCP or ADSP, build a "connection" between the two hosts. After the connection process, all sent data is guaranteed to reach its destination reliably and in-order -- until the stream is broken by one of the hosts or the actual network link fails.

Let's compare these types of communication with something easy to understand, say a water fight. When you throw a water balloon at someone, you may or may not hit them, but you make a best effort -- this is basically what datagrams do. Sending a broadcasts is similar, but instead hitting of a single target, you use a large water gun that can spray many people at once.

A transaction is where you keep lobbing water balloons at someone until you hit them, and they start lobbing them back at you in response. Finally, if you want to make sure someone really gets wet, you'll simply take the hose and put it down their pants -- giving them a pretty constant stream of water.

Datagrams are simple packets that carry data from one host to another. When a packet arrives, the network stack hands the data inside and the length to the waiting application. Due to the competitive nature of network communications, these packets are sometimes dropped by busy routers or corrupted by electrical noise. Most network stacks use simple checksums to validate these packets, but it's a good idea for higher level software to perform additional sanity checks.

The fundamental layer for Internet data exchange is IP, or Internet Protocol. Every other Internet protocol is built upon this, including TCP or UDP. The datagram protocol used by normal applications for data exchange is UDP, or User Datagram Protocol. Because IP and UDP are not reliable, applications will perform transactions to add reliability on their own -- or use the TCP stream protocol.

A broadcast is just a datagram read by many hosts on the same network at once. A multicast is similar, but hosts join a "multicast group" so they can receive any packets sent to that group's address. Sending a single packet to many hosts is much more efficient than sending it to each host one at a time. The biggest drawback is that broadcasts may fail to reach every listener than a datagram that's sent to a specific host.

A transaction is an ordered sequence of packets between two hosts. They provide reliable exchange of data in moderate amounts (data transactions), or can manage a specific chain of events (control transactions).

The simplest type of transaction is sending a "request" packet, and waiting for a "response" packet from the remote host -- in the form of an acknowledgement or some requested data. Other kinds of transactions may use more request and response packets in different combinations. Transactions are suitable for many kinds of lightweight exchange, because they are faster than streams at the cost of extra work by the application.

Stream protocols are optimized for transmitting large amounts of data quickly, making best use of bandwidth and resending any lost packets automatically. The network layer assembles incoming data in order, so that the application receives it as a continuous stream (hence the name). Since most stream protocols don't preserve packet boundaries, the application must scan the data to extract relevant messages.

For example, TCP is the reliable stream protocol for Internet communications. TCP knows how much data the application has sent, and dynamically selects the best packet size. On the flip side, sporadic bursts of data or poor network conditions may cause stream data to stall for short periods (called "flow control"). There are options to avoid this, but they can impact data throughput.

When you write your network code, you need to balance how much work you want to perform against how much control you need over the data. Streams are well-suited for file transfer, but game designers often use simple datagram or transaction protocols to get good performance with lower latency.