Unicasting versus Broadcasting Consider an application in which information must be sent to many clients simultaneously . An Internet teleconferencing system is one example. Another is a server that sends out periodic time synchronization signals. You could implement such a system using conventional network protocols in a couple of ways: -
Using TCP Accept incoming connections from clients that wish to subscribe to the service, and create a connected socket for each one. Call syswrite() on each socket every time you need to send information. -
Using UDP Accept incoming messages from clients and add each client's IP address and port number to a list of subscribers. Each time we want to send information, we iterate over each client's destination address and call send() on the socket, just like we did in the chat server in Chapter 19 (Figure 19.5). Both these solutions are known as "unicasting" because each transmitted message is addressed to a single destination. To send identical messages to more than one destination, we have to call syswrite() or send() multiple times. Although unicast approaches are effective in many cases, they have a number of disadvantages: -
Unicast is inefficient for large networks. In unicast applications, it may be necessary to transmit multiple copies of the same information across the local area network and its routers. In a video-streaming application, for example, the same frame of video may have to be retransmitted thousands of times. -
The destination must be known in advance. By definition, to send a unicast message the sender must know the address of the recipient. However, there are a handful of cases in which it is impossible to know the recipient's address in advance. For example, in the Dynamic Host Configuration Protocol (DHCP), a newly booted computer must contact a server to obtain its name and IP address. However, in a classic chicken-and-egg problem, the client doesn't know the server's IP address in advance, and the server can't send a unicast message back to it unless it has an IP address. -
Unicast doesn't allow anonymity. A corollary of (2) is that a host receiving unicast messages can't be anonymous. The peer needs its socket and IP address in order to get messages to it. However, there are many applications, including the video-streaming application that we have been discussing, in which it is neither necessary nor desirable for the server to know which clients are receiving the video stream. Broadcasting and multicasting (the next chapter's topic) break out of the unicast paradigm by allowing a single message transmitted by a host to be delivered to multiple addresses. The server does not need to maintain multiple sockets or to call send() or syswrite() several times. Each message is placed on the local area network only once, and distributed to the other machines on the LAN in a way designed to minimize the burden on the network. Furthermore, broadcasting and multicasting allow "resource discovery," a process that allows one host to contact another without knowing its address in advance. This same feature enables anonymous listeners to receive messages without making their presence known to the sender. |
