Shacklette Technical.Sockets.Part.2.Multicast.newx

Download Report

Transcript Shacklette Technical.Sockets.Part.2.Multicast.newx

Lecture Class 3
Advanced Socket Programming:
Broadcast & Multicast Concepts
Broadcast and
Multicast Concepts
See syllabus for supporting links
Unicast Review
Our discussion so far has been about unicast sockets,
where one server talks directly (and individually) to one
or more clients
TCP is unicast biased—it can only talk to unicast
addresses
Unicast works across both TCP and UDP connections
Unicast Datagrams
Broadcast Concepts
Multicasting is supported in IPv4 but is mandatory in
IPv6
Broadcasting has been dropped in IPv6 (IPv4
broadcasting must be recoded to multicasting in IPv6)
Broadcasting and multicasting only work across UDP—
not TCP
Broadcast Concepts
Key difference between unicast and broadcast:
Whereas unicast sends a message from one NIC* to
another NIC*, broadcast sends the same message to all the
NICs across a sub-network
Thus broadcasting implements a one-to-many model
In IPv4, broadcasting is used in ARP, BOOTP, NTP, and
routed
Broadcast Concepts
In IPv4, broadcasting is used in
Address Resolution Protocol (ARP)
IP address of X.X.X.X please ID yourself with hardware
address
Bootstrap Protocol (BOOTP predecessor to DHCP)
From 0.0.0.0 to 255.255.255.255 broadcast
Network Time Protocol (NTP)
time broadcast to all clients on a LAN
routed (broadcasts its routing table on the LAN
Broadcast Concepts
A broadcast goes out to every host on the subnet, which
includes the sender itself (if the sender has bound to the
target port)
So, every IPv4 host on the subnet receives the broadcast
and must completely process the UDP datagram all the
way up the protocol stack, up to and including the
Transport Layer
What if only 10% of the computers on the LAN care
about the broadcast?
What if a high data rate is being sent, as in audio or
video?
Broadcast Datagrams
Sending Broadcasts
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled,
sizeof(enabled));
You must set the originating socket option to
SO_BROADCAST in order to avoid error
EACCES (except Solaris 2.5)
Then call sendto(X.X.X.255) as usual (remember:
you are using SOCK_DGRAM and UDP)
Note that each individual datagrams sent out to
X.X.X.255 is a unicast datagram
Multicast Concepts
Whereas broadcast is a shotgun approach sending the
same datagram to every node on the network, multicast
is a full barrel shotgun, sending a "tight group" to a predefined subset of nodes on the network
A multicast datagram is only received by those hosts
interested in such receipt
Multicast thus sits "in between" unicast and broadcast
Note: We will skip PIM (Protocol Independent
Multicast and IGMP (Internet Group Management
Protocol)
Multicast Distribution Models
One-to-Many (1-M)
Many-to-Many (M-M)
Many-to-One (M-1)
Audio/Video (lectures,
presentations, concerts)
Conferencing (A/V
conferencing,
whiteboards)
Resource Discovery
(location services, device
discovery)
Push
Media/Announcements
(news, weather, time)
Games (multi-player,
simulators)
Data Collection (data
monitoring applications,
video surveillance)
Distribution (binary
executables)
Resource Sharing
(distributed databases)
Miscellaneous (auctions,
polling)
Monitoring (stock prices)
Distributed OS
(concurrent
collaboration, distance
learning)
Unicast vs. Multicast
©Cisco, see also Williamson, op. cit.
Bandwidth Efficiency
Williamson, Developing IP Multicast Networks, v1.
Scalability
Unicast
Multicast
Makofske & Almeroth, Multicast Sockets: Practical Guide for Programmers
IPv4 Multicast Concepts
Whereas broadcasting is normally limited to a LAN
subnet, multicasting can be used on a LAN or a WAN
(e.g. MBone)
Class D addresses in the range of 224.0.0.0 through
239.255.255.255 is the IPv4 multicast address range
224.0.0.1 is the all-hosts group
224.0.0.2 is the all-routers group
IPv4 Multicast Datagrams
IPv4 Multicast Address Ranges
While technically any Class D addresses in the range of
224.0.0.0 through 239.255.255.255 can be used...
The Address range 224.0.0.0 through 224.0.0.255 (aka
224.0.0.0/24) is termed the link local range
These packets are never forwarded by a multicast
router, and are reserved for low-level topology discovery
or maintenance protocols
Gist is you should stay away from 224.0.0.X
Bits and Bytes
The high-order 24 bits of an Ethernet (not token ring)
IPv4 multicast address is always:
01:00:5E (always 01:00:5E:00 effectively)
The high-order byte of an IPv6 multicast address is
always FF. The FF is followed by:
4-bit flags (well-known = 0; transient = 1)
4-bit scope (how "far" the packet travels)
IPv4 Scoping
IPv4 does not define scope, but uses a Time To
Live (TTL) value in the IP header
A TTL value of 0 means node-local
A TTL value of 1 means link-local (subnet only)
A TTL value of 2-31 means site-local (subnet only)
A TTL value of 32-63 means region-local
A TTL value of 64-127 means "continent"
A TTL value of 128-255 means global scope
IPv6 Scoping
node-local
link-local
site-local
organization-local
global
Administrative Scope
Administrative scope is 239.0.0.0 to 239.255.255.255
Organizations must configure routers never to
forward multicast packets destined to these addresses
In summary:
The Reality of Global Scope
So it sounds like Multicast is the solution for any wide
area distribution, right?
Not so fast...
Firewalls almost never accept incoming Multicast
messages
Most organizations configure routers to never let
Multicast messages out
ISP routers never forward Multicast messages
And this includes commercial applications
So How is this Done?
Multicast messages need to be encapsulated in some
fashion in order to "pass" muster
Protocol Independent Multicast is sometimes used to
wrap Multicast messages and forward those messages over
a VPN (PIM=>GRE=>IPsec)
You can always write your own Multicast router
Joining In
In order for a host to receive multicast messages, that
host must join the multicast group and bind() a UDP
socket to a port for receiving multicast messages
Joining is done via a call to setsockopt():
struct ip_mreq mcastreq;
setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP,
&mcastreq, sizeof(mcastreq));
The IP layer then tells the datalink layer to receive
Ethernet packets destined for this node (in our
example, to 01:00:5E:00:01:01)
IPv4 Multicast Datagrams
Multicast Request Structure
struct ip_mreq {
struct in_addr imr_multiaddr; //IPv4 mcast address
struct in_addr imr_interface; //IPv4 local interface
};
struct ipv6_mreq {
struct in6_addr imv6mr_multiaddr; //IPv6 mcast addr
unsigned int imv6mr_interface; //interface index or 0
};
If the local interface is INADDR_ANY (IPv4) or an index
of 0 (IPv6), the kernel will choose the local interface for
the app
Joining the Multicast Party
Nothing is required for the server to actually send a
multicast message...the server does not even have to join
the multicast group itself
As multicast support in IPv4 is optional for any host, any
host that has specifically not joined the group will ignore
multicast messages at the datalink layer
Joining the Multicast Party
More than one join is allowed on a given socket
as long as each join is for:
a different multicast address; or
for the same multicast address but different interface
There may exist a limit
(IP_MAX_MEMBERSHIPS in socket.h or in.h)
to the number of joins on a single socket
(BSD/OSX/Linux defines as 20)
Joining the Multicast Party
If a host has joined one or more multicast groups, the
datalink layer passes the message to the IP layer
The IP layer checks to see if this message was sent to a
multicast group this node has joined
If so, the IP layer hands the packet to the UDP layer for
direct processing by the specified server port
Any vs. Specific Sourcing
Any-Source Multicast (ASM): By default, any
source is accepted. Individual sources may be
turned off and back on as needed over time. This
is also known as "exclude" mode, since the source
filter contains a list of excluded sources.
Source-Specific Multicast (SSM): Only sources in a
given list are allowed. The list may change over
time. This is also known as "include" mode, since
the source filter contains a list of included sources.
SSM assumes a one-to-many model
Join Socket Options
Six socket functions may be set to manage group
membership
Socket Option *
Meaning
IP_ADD_MEMBERSHIP
IPV6_JOIN_GROUP
MCAST_JOIN_GROUP (generic)
Join a particular any-source multicast group on a specified local
interface.
IP_DROP_MEMBERSHIP
IPV6_LEAVE_GROUP
MCAST_LEAVE_GROUP (generic)
Leave a particular any-source multicast group on a specified local
interface (auto-leave on socket close)
IP_BLOCK_SOURCE
MCAST_BLOCK_SOURCE
Block receipt of messages on this socket from a given group (may
be useful in denying rogues and DOS attacks)
IP_UNBLOCK_SOURCE
MCAST_UNBLOCK_SOURCE
UnBlock (open) receipt of messages on this socket from a
previously blocked group
IP_ADD_SOURCE_MEMBERSHIP
MCAST_JOIN_SOURCE_GROUP
Join a source-specific group on a specific local interface
IP_DROP_SOURCE_MEMBERSHIP
MCAST_LEAVE_SOURCE_GROUP
Leave a source-specific group on a specific local interface
*See Stevens Unix Network Programming, v1, 3rd ed. for structures
Outbound Socket Options
There are three socket functions that may be set when
using multicast sockets to send messages
All three options are set with setsockopt() and are
optional:
Socket Option
Meaning
IP_MULTICAST_IF
IPV6_MULTICAST_IF
Specify the default interface for outgoing multicast datagrams sent on
this socket
IP_MULTICAST_TTL
IPV6_MULTICAST_HOPS
Set the TTL (IPv4) or hop limit (IPv6) for outgoing multicast
datagrams (both default to 1 which restricts to local subnet only)
IP_MULTICAST_LOOP
IPV6_MULTICAST_LOOP
Enable or disable loopback of multicast datagrams (default is enabled).
Enables sending host receipt of datagrams sent, but only if
host has joined the multicast group (cf. Broadcast)
Joining Review
So, for a node to receive multicast datagrams, the client
must:
call setsockopt() with socket option
IP_ADD_MEMBERSHIP (IPv4) to join the multicast
group and
call bind() to bind to a specific port on which to receive
the multicast messages
For more information on multicast, see:
http://tools.ietf.org/html/rfc3678
Multicast Sender (IPv4)
Create a socket:
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); //or 0
Call setsockopt for SO_REUSEADDR (optional)
Call setsockopt to set the TTL:
unsigned char mc_ttl = 1;//keep to localnet
setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL, (void*)
&mc_ttl, sizeof(mc_ttl)));
Send data as usual
close() the socket when done
Multicast Receiver (IPv4)
Create a socket:
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); //or 0
Call setsockopt for SO_REUSEADDR
Call bind() as normal
Call setsockopt to join the multicast group:
struct ip_mreq mc_req; //multicast request structure
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void*) &mc_req, sizeof(mc_req));
Send and receive data as usual
Call setsockopt to leave the multicast group when done:
setsockopt(sock, IPPROTO_IP, IP_DROP_MEMBERSHIP, (void*) &mc_req, sizeof(mc_req));
close() the socket when done
The Downside
IP Multicast over UDP suffers from the standard
limitations of the IP protocol itself with UDP:
Unreliable packet delivery
Duplicate packet delivery
Network congestion (as there is no built-in congestion
avoidance mechanism as in TCP)