Reliable byte stream
- 2 min read
- 2 chapters
Related on Lably
Through Computer network, Communication and Internet
The classic example of a reliable byte stream communication protocol is the Transmission Control Protocol, one of the major building blocks of the Internet.
A reliable byte stream is not the only reliable service paradigm which computer network communication protocols provide, however; other protocols (e.g. SCTP) provide a reliable message stream, i.e. the data is divided up into distinct units, which are provided to the consumer of the data as discrete objects.
Mechanism
Communication protocols that implement reliable byte streams, generally over some unreliable lower level, use a number of mechanisms to provide that reliability. Automatic repeat request (ARQ) protocols have an important role for achieving reliability.
All data items are identified with a sequence number, which is used both to make sure that the data are delivered to the entity at the other end in the correct order, and to check for lost data items. The receiver sends back acknowledgements for data items that have been successfully received; a timer at the sender will cause a timeout if an acknowledgement is not received within a reasonable round trip time, and the (presumably lost) data will then be re-transmitted. To check that no data items are damaged, a checksum is used; one is computed at the sender for each block of data before it is sent and checked at the receiver. Erroneous or missing data are reported to the sender, in order that it may retransmit the same. Any duplicated data items are discarded.
Sign in to keep reading
One more chapter is free with a Lably account.
Head-of-line blocking
Head-of-line blocking can occur in reliable byte streams: if packets are reordered or lost and need to be retransmitted (and thus arrive out-of-order), data from sequentially later parts of the stream may be received before sequentially earlier parts of the stream; however, the later data cannot typically be used until the earlier data has been received, incurring network latency. If multiple independent higher-level messages are encapsulated and multiplexed onto a single reliable byte stream, then head-of-line blocking can cause processing of a fully-received message that was sent later to wait for delivery of a message that was sent earlier. This affects, for example, HTTP/2, which frames multiple request–response pairs onto a single stream; HTTP/3, which has an application-layer framing design and uses datagram rather than stream transport, avoids this problem. The latency degradation from head-of-line blocking depends on the underlying packet loss rate and round-trip time, with higher losses producing worse latency. Without changing the stream abstraction, reducing packet loss can reduce the harm from head-of-line blocking; an alternative is to implement the reliable byte stream using forward error correction to send redundant data so that a certain amount of loss can be tolerated without incurring retransmissions.