Alex Mailer

The  approach  in  this article is  to  build  out  the  API  and  its  options  through  the  dis- cussion  of  simple  examplesmmulticast  sender  and  receiver  programs.  Sockets  are  an  application  programming  interface  (API) that  provide  basic  function  calls  to send  data across  a network. Originally developed  as part  of the Berkeley Standard Distribution (BSD) of Unix,  sockets have been expanded  to be  included  in almost all Unix variants, Microsoft Windows,  MS-DOS, Apple MacOS,  OS2,  and  newer  high-level  languages  such  as  Java  and  C# (pronounced  “C  sharp”).  Almost  anybody  who  has  done  modern  network  programming  is familiar  either with  the  socket API itself or with  a higher-level API that utilizes  sockets  “under the  hood.”

The  most  common  use  of  the  sockets  API  is  to  send  a  TCP  data  stream  from  one host  to  another.  TCP adds  important  features  like  connections,  multiplexing/demultiplexing, in-order  delivery,  reliability,  and  congestion  control  on  top  of  the  IP  layer.  As  discussed  previously, the one-to-many transmission of multicast packets makes use of TCP and its services impossible. Instead,  multicast  transmission  is  integrated  into  the  User  Datagram  Protocol (UDP). Of  the  five TCP  services  listed,  UDP provides  only multiplexing/demultiplexing. There is no  notion of connections,  in-order  delivery,  reliability,  or  congestion  control. Obviously, UDP is  a very basic network protocol. As a result,  it has  a  straightforward API. As  an  application programmer, you create  a  logical  “socket,” which is  a handle  to  the network endpoint  from which data  can be  sent  and  received.  If the goal is  to  send UDP packets,  packets can  simply be  sent  on  the  socket  to  a  specified  host  address  and  port. 

If  the  goal  is  to  receive UDP  packets,  the  additional  step  of  “binding”  the  socket  needs  to  be  performed.  This  step notifies  the  protocol  stack  that  it  should  begin  forwarding  packets  destined  for  that  port  to the  application. Then  the  application can execute  a  “read”  and wait  to begin receiving packets. Unlike TCP, no  formal establishment of a connection is required.  If the receiver is not listening, the  sender  will  not  know  and  the  packets  will  disappear  into  the  ether. 

If  the  sender  is  not sending,  the  receiver will wait  forever  in vain  (or  at  least  until  the  application  is  terminated, either programmatically or by a  frustrated  user).  If a packet  is  lost,  the  receiver may not  even be able  to detect it. Furthermore,  there  is no built-in mechanism within the protocol to alert  the sender  to  resend  the missing  data. Any detection  or  retransmission  of  lost  packets  is  strictly up  to  the  application  level  to  deal with. At first glance, one might assume  that  these are fatal flaws in the design of UDP.

However, this  is not  the  case.  For  some  kinds  of applications, UDP  is much more  appropriate  than TCP. For  example,  consider  an  application  that  requires  a  constant  stream  of  packets  and  where lost  packets  do  not matter  (e.g.,  streaming  audio  or video). UDP  is well  suited because  it  does not  stop  and  retransmit  lost packets.  Retransmitted packets  are useless  because  the  data will be  out  of date before  it  can be  re-sent  and  received. UDP allows  application developers  to  add more  lightweight  reliability  schemes  than  TCP  (e.g.,  partial  reliability  for  a  streamed  song). Also,  since  TCP  has  all  the  overhead  of  establishing  and  closing  connections,  UDP  can  be significantly  faster.  This  is  even more  important  for  multicast  where  the  time  saved  in  not having  to  establish  a  connection  to  every  receiver  could  be  huge.  So,  in  fact,  UDP  is  widely used  in  streaming  applications  and  for  critical  Internet  protocols  such  as  the  Domain Name System  (DNS), Network File System (NFS), and  Simple Network Management Protocol  (SNMP). In  the  next  two  sections, we  are  going  to  look at  the  details  of UDP  socket  calls,  and  the additional  calls  and  considerations  introduced when multicasting packets.