diff --git a/lectures/03-Lecture3-UDPProgramming.md b/lectures/03-Lecture3-UDPProgramming.md index 286e3e5..b963383 100644 --- a/lectures/03-Lecture3-UDPProgramming.md +++ b/lectures/03-Lecture3-UDPProgramming.md @@ -133,7 +133,7 @@ In the second constructor, we **specify a port number**. This means that we will As you remember, **applications that use TCP as a transport-layer protocol always see a pair of processes communicate with each other**. The server listens on a known port, the client makes a connection request on that port and when they are connected, they exchange data until the connection is closed. Standard one-to-one communication, which relies on [**unicast**](http://en.wikipedia.org/wiki/Unicast) data transmission. Another way to look at it is that the TCP segments that carry application-level messages are **always going to a single destination** (defined by the destination IP address and the destination port). From your study of the TCP/IP stack and of protocols such as [ARP](http://en.wikipedia.org/wiki/Address_Resolution_Protocol) (used to *discover* the MAC address corresponding to an IP address), you should remember that there are **other data transmission models** within a network of nodes: - + * [**Broadcast**](http://en.wikipedia.org/wiki/Broadcasting_%28networking%29) is one of them, where **a message is distributed to all nodes in the network**. As an analogy, think of what happens when **your mailbox is flooded with commercials** (just like your neighbour's). You didn't ask to receive the commercials and the advertising business did not need to know you in order to send you the glossy brochure with weekly deals. Everybody living in the city got them. * [**Multicast**](http://en.wikipedia.org/wiki/Multicast) is another one, where **a message is distributed to all *interested* nodes in the network**. What does it mean for a node to *be interested* and how does it work in practice? Well, multicast protocols rely on the notion of *group*, which you can think of as **a kind of radio channel**. Just like music amateurs can decide to listen to particular radio channels, nodes in a network can decide to listen (i.e. *subscribe to*, *join*) to specific multicast groups. When other nodes (playing the role of the radio station) send messages to the group, then **all subscribers to that group will receive a copy of the message**. @@ -273,7 +273,7 @@ There are **at least two methods for supporting service discovery** in a dynamic 1. **The first one consists for the service providers to periodically advertise their presence**. Imagine a printer that would publish a UDP datagram on a multicast group every 5 seconds. A laptop that would be looking for available printers would create a datagram socket, join the multicast group (effectively expressing its interest in printers) and would thus receive the presence datagrams. The presence datagrams should contain the contact details (i.e the data that is required for the laptop to initiate an interaction with the printer and use its printing service). -2. **The other one works in other direction.** It consists for the printers to join a multicast group and for the printers to send datagrams containing a message with the semantic *"I am looking for a printing service"*. When receiving these requests, the printers should send back a message informing the laptop that they are available and giving the required contact details. +2. **The other one works in other direction.** It consists for the printers to join a multicast group and for the laptops to send datagrams containing a message with the semantic *"I am looking for a printing service"*. When receiving these requests, the printers should send back a message informing the laptop that they are available and giving the required contact details. ## Resources