|This article does not cite any references or sources. (December 2009)|
||It has been suggested that this article be merged into Bitstream. (Discuss) Proposed since October 2012.|
Formally, a byte stream is a certain abstraction, a communication channel down which one entity can send a sequence of bytes to the entity on the other end. Such channel is often bidirectional, but sometimes unidirectional. In almost all instances, the channel has the property that it is reliable; i.e. exactly the same bytes emerge, in exactly the same order, at the other end.
Less formally, one can think of it as a conduit between the two entities; one entity can insert bytes into the conduit, and the other entity then receives them. This conduit can be ephemeral or persistent.
On most operating systems, including Unix-like and Windows, access of any file from a process is an example of a byte stream. In particular each process has three standard streams, that are examples of unidirectional byte streams. A pipe mechanism is often used to connect them between processes, to enable process-to-process byte streams.
One well-known example of a communication protocol which provides a byte-stream service to its clients is the Transmission Control Protocol (TCP) of the Internet protocol suite, which provides a bidirectional byte stream.
The Internet media type for an arbitrary byte stream is application/octet-stream. Other media types are defined for byte streams in well-known formats.
Often the contents of a byte stream are dynamically created, such as the data from the keyboard and other peripherals (/dev/tty), data from the pseudorandom number generator /dev/urandom, etc. In those cases, when the destination of a byte stream (the consumer) uses bytes faster than they can be generated, the system uses process synchronization to make the destination wait until the next byte is available. When bytes are generated faster than the destination can use them, there are several techniques to deal with the situation:
- When the producer is a software algorithm, the system pauses the producer with the same process synchronization techniques.
- When the producer supports flow control, the system only sends the "ready" signal when the consumer is ready for the next byte
- When the producer can't be paused -- it is a keyboard or some hardware that doesn't support flow control -- the system typically attempts to temporarily store the data until the consumer is ready for it, typically using a double buffer or a queue. Often the receiver can empty the buffer before it gets completely full. A producer that continues to produce data faster than it can be consumed, even after the buffer is full, leads to unwanted buffer overflow, packet loss, and network congestion.