The Open Systems Interconnection model (OSI model) is a conceptual model that characterizes and standardizes the communication functions of a telecommunication network. The OSI model defines a series of 7 abstract layers; each layer accomplishes a specific task (e.g., link, transport, application). Nevertheless, it does not specify the implementation, the structure, or the technology. Contrary, different standards define various deployments, e.g., TCP/IP or IPX/SPX. The actual implementation may vary in accord with the desired goal. Currently, TCP/IP is the most common implementation of the OSI model. It fulfills the layers defined by the OSI model with a suite of protocols belonging to the first 4 layers: link, Internet, transport, and application.
Reliability and performance (TCP vs. UDP)
In the TCP/IP model, the Internet Protocol (IP) implements the third network layer of the OSI model and the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) carry out the fourth transport layer. Although TCP and UDP belong to the same level they act differently.
The TCP protocol provides reliable, ordered, and error-checked streams of bytes between 2 endpoints (also known as Unicast connections). Contrary, applications that do not require reliable data stream service may use the UDP protocol. The latter reduces the latency by losing in reliability. A second advantage of the UDP protocol (in the IPv4 implementation) is the possibility to efficiently transmit to multiple ends belonging to the same sub-network, i.e., Broadcast connections. Consequently, in the latter scenario, the upper layers must care for the reliability and the order of the received packets.
In other words, the choice between TCP and UDP requires a tradeoff among performance and reliability. For instance, a VoIP application prefers UDP connections that reduce latency and give a better user experience; Contrary, an IP radio application chooses TCP connections that reduce glitches by increasing the latency.
Endpoints’ role (server vs. client)
In a point-to-point communication schema, 2 devices perform as server and client, respectively. Typically, the server is the device that waits for incoming requests on an IP publically reachable. The client, instead, is the device that starts the connection toward the server by querying the server IP address. In a point-to-multipoint communication schema, a single device acts as a server and multiple devices work as clients. The Broadcasters support both point-to-point than point-to-multipoint streams.
Point-to-point (unicast connections)
The point-to-point unicast connection includes several common usage scenarios such as web radios, office conferences, mall audio diffusion, theater broadcast, thematic streams, etc. Let see how Broadcasters work.
The basic task for a Broadcaster is to receive an audio stream from a remote provider (e.g., web radios). In this configuration, a Broadcaster acts as a TCP client (conf. examples). The Broadcaster contacts the remote server and playbacks the incoming stream on the Line-out. Moreover, this scenario can be expanded by replacing the remote server (e.g., web radios, VLC, relay servers) with a Broadcaster configured as a TCP server (Unicast Audio transmitter).
TCP server (Unicast audio transmitter)
TestThe Standard and Pro Broadcasters also work as audio transmitters. In this scenario, the Broadcaster implements a TCP server. The server remains listening to incoming connections on a user-specified port. Clients can start a connection by knowing the IP address assigned to the TCP server (conf. examples). When a connection is established the transmitter Broadcaster sends the Line-in audio stream to every connected client.
Asynchronous point-to-multipoint (Broadcast connections)
The point-to-multipoint broadcast connection covers a different group of scenarios where many audio players must playback the same sound such as music, messages, warning, advice, spots, etc. Let discover how to use Broadcasters.
All Broadcasters implement the UDP client (Broadcast audio receiver). In this configuration, many Broadcasters synchronize with a broadcast UDP stream (by relying on RTP protocol) and altogether playback the incoming stream on the Line-out (conf. example).
The Standard and Pro Broadcasters can act as a UDP server (Broadcast audio transmitter). In this configuration, a Broadcaster transmits UDP datagrams to every receiver belonging to the same network (see conf).
Synchronous point-to-multipoint (Real-time playback)
This scenario is a particular sub-case of broadcast connections in which many audio players must be able to synchronize audio playback like a single broad player. Also, receivers may belong to different networks. See how Broadcasters address that.
A Real Time Streaming Protocol (RTSP) is a network control protocol designed for synchronizing audio players. Working here!!!
The Standard and Pro Broadcasters can perform as an RTSP audio transmitter. Working here!!!
Point-to-multipoint (Relay server)
Finally, to allow many simultaneous connections an appropriate infrastructure must be realized. In that case, the solution consists in employing a relay server. What can Broadcasters do?
Simple broadcast connections are not suitable for a large number of connections. More in deep, to have a wide number of simultaneous clients belonging to different sub-networks a relay server must be used (e.g., Icecast or SHOUTcast). A relay server requires more hardware resources compared to Broadcaster products, therefore, an appropriate analysis must be planned to sizing the relay server.
Even in this case, a Broadcaster can simplify the installation because it can work as a source transmitter. In other words, a source transmitter Broadcaster receives, encodes, and transmits the Line-in audio stream to a relay server. Then, the relay server distributes the source audio stream by accepting hundreds of TCP client connections. Finally, several clients (e.g, Broadcasters) receive and playback the audio stream on the Line-out.