Bitstream

In practice, bitstreams are not used directly to encode bytestreams; a communication channel may use a signalling method that does not directly translate to bits (for instance, by transmitting signals of multiple frequencies) and typically also encodes other information such as framing and error correction together with its data.^{[citation needed]}

The term bitstream is frequently used to describe the configuration data to be loaded into a field-programmable gate array (FPGA). Although most FPGAs also support a byte-parallel loading method as well, this usage may have originated based on the common method of configuring the FPGA from a serial bit stream, typically from a serial PROM or flash memory chip. The detailed format of the bitstream for a particular FPGA is typically proprietary to the FPGA vendor.

In mathematics, several specific infinite sequences of bits have been studied for their mathematical properties; these include the Baum–Sweet sequence, Ehrenfeucht–Mycielski sequence, Fibonacci word, Kolakoski sequence, regular paperfolding sequence, Rudin–Shapiro sequence, and Thue–Morse sequence.

On most operating systems, including Unix-like and Windows, standard I/O libraries convert lower-level paged or buffered file access to a bytestream paradigm. In particular, in Unix-like operating systems, each process has three standard streams, which are examples of unidirectional bytestreams. The Unix pipe mechanism provides bytestream communications between different processes.

Compression algorithms often code in bitstreams, as the 8 bits offered by a byte (the smallest addressable unit of memory) may be wasteful. Although typically implemented in low-level languages, some high-level languages such as Python^[1] and Java^[2] offer native interfaces for bitstream I/O.

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 bytestream.

The Internet media type for an arbitrary bytestream is application/octet-stream. Other media types are defined for bytestreams in well-known formats.

Often the contents of a bytestream 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 bytestream (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 and the producer is a software algorithm, the system pauses it 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 not be paused—a keyboard or some hardware that does not support flow control—the system typically attempts to temporarily store the data until the consumer is ready for it, typically using 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, network congestion, and denial of service.