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:
http://www.javasoft.com/jdc
ë 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
language
ë à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
addresses
ë 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
future
ë 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
finished
 %%| )!
ë Static construction using a factory method
ë  

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

 


ë Some useful methods:


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


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

 

ë  

     
 
  | 
" 
      


      !
"#

˜ 
  

 

 

$ %
 

   &
'! ' '&

   ˜
 $ 
 

 
 

( %
 

   &$)*+,-($).&

   ˜ ( 
  
 $/' 
(

   ˜    

  ˜  

 ˜
 


0  







ë 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*   


    
   (

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)
0
(
0 

ë        is used by servers
so that they can accept incoming TCP/IP
connections
ë A server is a piece of software which
    and then provides some service on
request
ë      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
service
 %%  
&!
ë Listens on '
 port for incoming
connections
ë Creates a dynamically allocated port for
each newly established connection
ë Provides a Socket connected to the new
port
ë ½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:
ë    
0   
ë Also used to accept an incoming
connection (see ServerSocket)
 %%
)!
ë Can obtain access to input and output
streams
ë 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 ,

  

 


 6  
˜  







6 


  ˜  

    



  ˜ 

    




| 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
Internet
ë 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
communications
ë ½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
communication:
ë Local network broadcasting;
ë ½ulticasting (½BONE)
ë but there is no way to create one-to-many
streams using TCP/IP
 %%,  &!
ë DatagramPackets normally used as short
lived 
 for datagram messages:
ë Used to assemble messages before they are
dispatched onto the network,
ë or dismantle messages after they have been
received
ë 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   
ë  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
network
%   %,   

        


 ˜
! 4  6    0    


  
 

   :9  ;


˜
 

  
˜
6   

 
! 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
message
%   %,  Π

˜ ˜  ˜


    !" 
 ˜
! 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
u
  
ë 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
components:
ë The network address
ë The unique international address of the
network
ë The host address
ë The unique address of a specific host in the
net
ë There are three classes of network
address denoted class µA¶, µB¶ and µC¶
|u   

[ 

  

   

   

á  
 
u
  
ë 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
130.95.72.255
ë Broadcasts are  routed onto other
networks
½   &!
ë 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 ³
0)
ë ½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
224.0.0.1 to 239.255.255.255 specifically for
multicasting
½   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:  %%½ 


  

ë 224.0.0.1 All hosts within local subnet
ë 224.0.1.7 Audio news multicast
ë 224.0.1.12 Video from IETF meetings
ë 224.0.1.20 Expts. within local subnet
ë 224.0.1.25 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 '
ë <  #  # # = 
ë 
77 
ë $ & 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 '

77,

        


  
     
      ˜ 
 
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
socket.
ë 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 http://www.ietf.org -- you will be
able to download RFCs from here
ë ½ulticasting try reading the HOWTO which
is available from the URL:
http://ftp.southcom.com.au/LDP/HOWTO/...
½ulticast-HOWTO.html
£


ë Read through the code samples to
convince yourself you understand what¶s
going on
ë Sample code can be downloaded from
http://ciips.ee.uwa.edu.au/~gareth
ë If you can, run the examples

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