You are on page 1of 52




Gareth Lee
Department of Electrical and Electronic Engineering,
University of Western Australia
ë àava¶s network support
ë Addressing other machines
ë Communicating using TCP/IP
ë Communicating using UDP
ë Broadcasting and multicasting

  , Elliotte Rusty
Harold, O¶Reilly and Associates, 1997,
ISBN 1-56592-227-1
ë 0 

, Craig Hunt, O¶Reilly and
Associates, 1997, ISBN 1-56592-322-7
ë The àava Developer¶s connection:
ë The àavadoc documentation

ë ½echanisms by which software running on
two or more computational devices can
exchange messages
ë Desktop Computers
ë PDAs / Set Top Boxes / ½obile Telephones?
ë àava is a network centric programming
ë àava abstracts details of network
implementation behind a standard API
ë Portable (and future proof) . . .
ë but may be rather limiting


£ G G | 
 " #
$!  !





ë Abstracts away the details of the physical
network implementations (such as
Ethernet, Token Ring, AT½, Sonet)
ë All traffic uses the same rules to move
from machine to machine
ë Easy to write programs
ë Easy to build network hardware
ë Works with Datagrams: small discrete
packets of data (rather like a  )

ë A way of uniquely addressing machines
using 32 bit addresses: giving 4 billion
possible addresses (like a  
ë A system for numbering 
 on each
machine (like a 

ë Port numbers allow several services to
operate from a machine at the same time

ë Ports 20/21 File Transfer Protocol
ë Port 23 Telnet
ë Port 25 Simple ½ail Transport Proto.
ë Port 79 Finger
ë Port 80 HTTP
ë Port 110 POP3 (Post Office Protocol)
ë All well known ports in the range 1..1023

ë The Internet consists of a large number of
independent sub-networks (subnets)
ë A mechanism for relaying datagrams from
one network to another (
ë For routing to work each organisation
must have a well known prefix (all UWA
addresses start with the bytes 130.95)
ë . . but we don¶t use addresses very
efficiently and we¶re running out fast (UWA
doesn¶t need 65536 separate addresses)
ë The solution is IPv6 which uses 128 bit
ë Improves services such as multicasting
and secure communication
ë Several addresses per m2 of the Earth¶s
surface (3.4 x 1038 to be precise)
ë Not yet widely deployed by ISPs
ë Perhaps widely deployed in 2-4 years
ë Well written àava software should move to
IPv6 without modification/recompilation
ë One benefit of abstracted APIs
ë àava has a class     

which abstracts network addresses

ë Serves three main purposes:
ë Encapsulates an address
ë Performs name lookup (converting a host name
into an IP address)
ë Performs reverse lookup (converting the
address into a host name)
 %%| &!
ë Abstraction of a network address
ë Currently uses IPv4 (a 32 bit address)
ë Will support other address formats in
ë Allows an address to be obtained from a
host name and vice versa
ë Is immutable (is a  '
( object)
ë Create an InetAddress object with the address
you need and throw it away when you have
 %%| )!
ë Static construction using a factory method

ë   ( )! !#* 
ë   ( )+,-./0+1*


ë Some useful methods:

ë 2 #   ! 34 5! )&&&# !*6

ë 2 #   34 5! )-07-/01*6








$ %

'! ' '&



( %


   ˜ ( 





ë TCP is built on top of IP

ë Provides the illusion of a continuous flow
(or   ) of data between sender and
receiver (rather like a *
ë Splits up streams into strings of small
datagrams which are sent in succession
ë Contains an error recovery mechanism to
recover datagrams which are lost
ë 0*   



ë Used by FTP / Telnet / Finger and

numerous other network applications
ë Used by stream oriented servers such as
HTTP (as we will see in unit 2)
ë Can also be used to provide inter-process
communications (IPC) between the
applications on a single machine (such as
a X-windows clients and servers)

ë        is used by servers
so that they can accept incoming TCP/IP
ë A server is a piece of software which
    and then provides some service on
ë      is used by clients who
wish to establish a connection to a
(remote) server
ë A client is a piece of software (usually on a
different machine) which makes use of some
ë Listens on '
 port for incoming
ë Creates a dynamically allocated port for
each newly established connection
ë Provides a Socket connected to the new
ë ½aintains a queue to ensure that
prospective clients are not lost
ë Construction:
ë      0  1   
ë & #  (8 9#  9## & 4 
   & !
ë Some useful methods:
ë "8 & 4     !  ( 

ë  (   &   # &   #
ë ½ore details in the àavadoc (as always!)
ë Provides access to TCP/IP streams
ë Bi-directional communication between
sender and receiver
ë Can be used to connect to a remote
address and port by using the constructor:
ë Also used to accept an incoming
connection (see ServerSocket)
ë Can obtain access to input and output
ë Input stream allows reception of data from
the other party
ë '  '  

ë Output stream allows dispatch of data to

the other party
ë `''   `''  


 ÿ  ÿ  ÿ 


   ÿ   [      ÿ  

   ÿ      ÿ  
| 0  


!    23""456`3758 "30 ,









| 0  




  0 23""456`3758 "3






ï*    +
ë Datagrams are discrete packets of data
ë Each is like a parcel that can be addressed
and sent to an recipient anywhere on the
ë This is abstracted as the User Datagram
Protocol (UDP) in RFC768 (August 1980)
ë ½ost networks cannot guarantee reliable
delivery of datagrams
ï*(   +
ë Good for sending data that can naturally
be divided into small chunks
ë Poor for (lossless) stream based
ë ½akes economical use of network
bandwidth (up to 3 times the efficiency of
TCP/IP for small messages)
ë Datagrams can be locally broadcast or
multicast (one-to-many communication)
ë UDP can be used for economical point-to-
point communications over LANs
ë Unix NFS (Network File System)
ë NIS (a.k.a. Yellow Pages)
ë Datagrams can be used for one-to-many
ë Local network broadcasting;
ë ½ulticasting (½BONE)
ë but there is no way to create one-to-many
streams using TCP/IP
 %%,  &!
ë DatagramPackets normally used as short
 for datagram messages:
ë Used to assemble messages before they are
dispatched onto the network,
ë or dismantle messages after they have been
ë Has the following attributes:
ë Destination/source address
ë Destination/source port number
ë Data bytes constituting the message
ë Length of message data bytes
 %%,  )!
ë Construction:
ë 4  6  1   0   

ë Some useful methods:





ë  6 
ë DatagramPackets are 
 immutable so, in
principle you can reuse then, but . .
ë Experience has shown that they often
misbehave when you do -- create a new
one, use it once, throw it away!
ë Used to represent a socket associated with
a specific port on the local host
ë Used to send
receive datagrams
ë Note: there is no counterpart to
      ! àust use a
DatagramSocket with a   port
number so others know which address and
port to send their datagrams to
ë Construction:
ë 4     
  4  3# 4   !6
ë 4   
ë    (  #!( 34   6
ë Some useful methods:
4  6   9'6  
ë $   4#  ! #    &8
ë  4  6   6  
ë : #    !   4  !8 & 
ë . . . and a few more in the àavadoc
%   %,   
ë This example sends datagrams to a
specific host (anywhere on the Internet)
ë The steps are as follows:
ë Create a new DatagramPacket
ë Put some data which constitutes your message
in the new DatagramPacket
ë Set a destination address and port so that the
network knows where to deliver the datagram
ë Create a socket with a ( (

port number (if you are just sending from it)
ë Send the packet through the socket onto the
%   %,   


! 4  6    0    


   :9  ;



! 4   
%   %,  Π
ë The steps are the reserve of sending:
ë Create an empty DatagramPacket (and allocate
a buffer for the incoming data)
ë Create a DatagramSocket on an   socket
number to provide access to arrivals
ë Use the socket to receive the datagram (the
thread will block until a new datagram arrrives)
ë Extract the data bytes which make up the
%   %,  Π

˜ ˜  ˜

! 4  6    0    

! 4   +<-=






 ˜  ˜   


   ˜ ˜   

u - . * /
ë Several of the constructors/methods throw
exceptions which I have omitted
ë Each datagrams can only hold up to a
maximum of 64KB of data . .
ë . . but the underlying transport layer may
split the message into smaller packets (for
instance Ethernet uses about 1500 bytes)
ë Always remember that UDP is an
  " protocol: If any of the split
datagrams are lost the whole message will
be lost
ë Broadcasting allows a single datagram to
be sent to a group of listeners
ë The group consists of all the computers
within the local network
ë The previous code examples can be used
for broadcasting
ë àust change the address: each network
has a unique broadcast address
ë Each 32 bit IP number consists of two
ë The network address
ë The unique international address of the
ë The host address
ë The unique address of a specific host in the
ë There are three classes of network
address denoted class µA¶, µB¶ and µC¶





ë CIIPS has a class µC¶ network which has
the address 130.95.72
ë This portable computer has host address
134 within the CIIPS network
ë Each network has a single host address
which is set aside for broadcasts (either all
one bits or all zero bits)
ë The CIIPS network uses broadcast address
ë Broadcasts are  routed onto other
½   &!
ë Described in RFC1112 (August 1989)
ë ½ulticasting allows distribution of a
datagram to a group of listeners who are
not within the local network
ë Routers between networks need to pass
multicast datagrams. . but many do not!
ë The ½BONE is a way of tunneling
datagrams across the Internet between
  of multicast activity
½   )!
ë ½ulticasts are also sent to a special
address (known as a ³
ë ½ulticast groups need to be   in
advance. They are not derived from a
specific network/host address
ë ½ulticast groups identify a subject area (or
stream of content) rather than a specific
computer or network. They are more like a TV
channel number than a telephone number.
ë The IETF has set aside addresses from to specifically for
½   1!
ë To send to (or receive from) a multicast
group it is first necessary to   
  in the group
ë This results in an Internet Group ½anagement
Protocol (IG½P) message being sent to your
router (RFCs 988/1112/2236)
ë Then a datagram is created, addressed to
the group (and the chosen port)
ë àava has a specialised socket for
multicasting:  %%½ 


ë All hosts within local subnet
ë Audio news multicast
ë Video from IETF meetings
ë Expts. within local subnet
ë NBC Professional News
ë There are 268 million multicast addresses
(in IPv4) with 65 thousand ports in each!

ë Subclass of    4   
ë Constructed the same way
ë Adds some extra methods:
ë   2 ' 

2 '
ë ;   4 #   #     
ë   2 ' 

2 '
ë <  #  # # = 
ë $ & 4 #  ! &  (4 #
ë  77
%   %½  
ë Sending similar to the previous example. .
ë . . .but must register with the multicast
group and decide the longevity
ë The steps involved are:
ë Create the ½ulticastSocket.
ë àoin the multicast group(s) (on startup).
ë Create the DatagramPacket.
ë Send the packet through the socket.
ë Leave the multicast group (on exit).
%   %½  
! 8'
  2 ''
2 '



6 +<-=


  2 ''

2 '
%   %½ Œ 
ë The steps are:
ë Create a multicast socket on an   port.
ë àoin the multicast group (on startup).
ë Create an empty datagram.
ë Wait for datagram to be delivered on the
ë Unpack and use the datagram.
ë Leave the multicast group (on exit).
%   %½ Œ 
! 8'
  2 ''
2 '



˜  ˜   

  2 ''

2 '


ë The Internet Engineering Task Force (IETF)
which is at -- you will be
able to download RFCs from here
ë ½ulticasting try reading the HOWTO which
is available from the URL:

ë Read through the code samples to
convince yourself you understand what¶s
going on
ë Sample code can be downloaded from
ë If you can, run the examples

ë How was the presentation paced?
ë Was there enough (or too much) technical
ë Any areas of particular interest?
ë Comments regarding presentation style?