We propose a programming project to acquaint ourselves with
TCP/IP ‘multicast’ capabilities

0
1 0
1 1 0
1 1 1 0
1 1 1 1 0
32-bits
Class A address
Class B address
Class C address
MULTICAST address
Reserved
Address Range
0.0.0.0 - 127.255.255.255
128.0.0.0 - 191.255.255.255
192.0.0.0 - 223.255.255.255
224.0.0.0 - 239.255.255.255
240.0.0.0 - 247.255.255.255
The range of IPv4 NetworkLayer Addresses is subdivided into “classes” based on the high-order bits in these 32-bit addresses, with those which begin with “1110” (the Class D addresses) being allocated to multicasting

• The remaining 28-bits of an IP multicast address are used to identify the “group” that a datagram should be delivered to
• There are some special multicast groups whose addresses you should avoid using
– 224.0.0.1 (the all-hosts group)
– 224.0.0.2 (the all-routers group)
– 224.0.0.3 (address-purpose is unassigned)
– 224.0.0.x (for local administration purpose)

• Multicast applications should not use any multicastaddresses in the ‘special’ range
(i.e., 224.0.0.0 – 224.0.0.255) designated for use by utilities devoted to maintenance and administration of the local network
• So our example-programs define a ‘group’ whose IP-address lies outside this range, namely: 224.3.3.6 (easily remembered?)

Host A Host B Host C Host D Host E
Local Area Network
With IP-broadcasting, a datagram whose destination-address is equal to 255.255.255.255 will be received by every host on the local network
Host A Host B Host C Host D Host E
Local Area Network
With IP-multicasting, a datagram whose destination-address is equal to 224.3.3.6 would be received only by those hosts on the local network that have chosen to become ‘members’ of this specific multicast-group

Host A
Host B
Host C
Host D
Host E
Host F
Host G
Host H
Modern routers do not ‘forward’
broadcast datagrams, but they can be configured to ‘forward’ any multicast datagrams
Router
X
Router
Y
Host I
Host J
Host K
Host L
Host M
Host N
Host O
Host P (Older routers can use ‘tunneling’)

• Programming languages that support the
‘sockets’ interface can allow you to write client-andserver ‘multicast’ applications server client client client client
But obviously the TCP ‘connection-based’ protocol is NOT used in multicasting!

• We put up a very simple client-and-server multicast application on our class website, written in Python (for brevity)
– ‘multisend.py’ (the ‘server’ program)
– ‘multirecv.py’ (the ‘client’ program)
• The server just sends a ‘Hello’ message to current group-members once each second
• The client can be run on multiple hosts

• Write a multicast server-program (named
‘ deadline.cpp
’) that periodically sends out reminder-messages about upcoming duedates for course-assignments or exams
• Write the multicast client-program (named
‘ timeleft.cpp
’) that a student who desires to receive reminders can use to ‘join’ the server’s multicast-group

• Your programs are required to be written in the C++ language, so we have put the rewritten versions of our ‘ multisend ’ and
‘ multirecv ’ application-programs on the class website as demonstration examples

‘multirecv.cpp’ socket()
‘multisend.cpp’ socket() setsockopt(
REUSEADDR
) bind() setsockopt(
ADDMEMBERSHIP
) sleep( 1 ) sendto() recv() puts()

• For developing your own application, you will be sharing our local USF networks as the hardware ‘testbed’ for your C++ code
• You’ll be annoyed if everyone’s messages arrive and get displayed on your screen!
• So we need a different IP-multicast group address for each classmember
224.3.36.xxx
‘xxx’ equals 100 plus your number on the Instructor’s class-list (you can find it handwritten on your Midterm Exam)