Data Communication I

Lecture 4a

presented by

Werner Wild, CEO Evolution

Innsbruck, San Francisco, Zurich

Contact: info@evolution.at
Today’s Lecture Plan
 Globe, Review TCP , UDP
Resolver Discovery Services
 URN resolution breaks into 2 steps:
– finding the appropriate resolver (RDS), and
– then resolving the URN. kris RDS
fer: r
b e nd o
u
t o n: b z
e l l i ng .c o. n
e :nz:w elecom
on r n .t
r n: ph s k u
u
nd
i 2. A
13. F
Client . Fin
d ur
n:ph
one
:nz:
wel
4. + ling
64- t on:
4-5 bu b
55- end
555 orfe
5 r:kr URN
is
urn.telecom.co.nz
Resolver
Alternative Architectures
 Locating resources is a more difficult
problem if those resources are mobile.
 This includes people, hardware, data and
programs.
 Alternative architectures must be designed
to locate mobile resources.
– Globe
– Nomad
Globe
 The Globe system details a location service that
is designed to:
– scale globally (load distribution), and
– handle mobility (via locality of reference).
 Distributed Object Model:
– One ‘object’ is split over n hosts.
– Object is a composite -> unit of identity.
 Developed at Virje University in Holland.
 Globe Quad Tree (Load Balancing)
 The Globe location service divides the world geographically
using a quad tree.
 When load increases above a load threshold in a region, the
region is further divided.

Near empty regions

are (physically)
merged with
neighbors. But still
exist logically.
How it works (Insertion).
 A rooted hierarchical root Ref
Ref A,
A Ref B, ...

tree.
 Insertions start at leaf:
Ref B, Ref A
– bottom up,
– to the root, Ref B Ref A

 Root must contain all

references. Ref B Ref A

B A
How it works (Location).
 Searches also start at root Ref A, Ref B, ...
local leaf,
– geographic locality ->
Ref B, Ref A
root is not traversed,
– worst-case is to root Ref A
?
 Uses heuristics to
organize the nodes. ? Ref A

 B finds A
 A finds C B A C
How it works (Mobility).
 Updates also start at root Ref A, Ref B, ...
local leaf,
– geographic locality ->
root is not traversed, Ref A

– worst-case is to root
 Only need to update Ref A’
A

until we find an existing

reference, then update. Ref A
A’
 E.g. A moves to A’

A
Problems
 Root must know all references (Scale!).
– Uses heuristics to partition the root onto n
physical distributed machines.
 Searching is fast, but:
– only for logically close objects (A&C).
 Updating location due to mobility,
– slower the further the object moves.
 So, resolution times are inconsistent.
Nomad
 The Nomad Location Service is designed
– specifically to handle mobility, in
– large scale distributed systems.
 Application Object Cluster Model:
– n application objects per cluster,
– cluster is the unit of identity, and location.
 Developed in New Zealand
Review the Transport Layer
applications

transport protocol
technology
Layer Architecture
mail, file transfer, web
Application Application

tcp, udp
Transport Transport
ip
Internet Internet Internet

Media access Media access Media access

Roles and Responsibilities
 Logicalcommunication between processes
 Message oriented
– Best effort, single message delivery
 Connection oriented
– Sequenced, error free, stream
– Flow and congestion control
The Transport Layers
application

?
UDP TCP

 User Datagram  Transmission Control

Protocol Protocol
 Independent segments  Reliable stream
 Best effort delivery  Manages segments
(parts of stream)
Multiplexing
application

UDP TCP

IP

 IP (network layer) receives all segments for host

 IP delivers to appropriate transport layer
 Transport protocol delivers to socket (application)
The Role of Headers
transport header
source destination other
network header port port header
data

source destination
protocol
host host

 Eachprotocol has a header

 Network header addresses machines
– Denotes protocol (TCP or UDP)
 Transport header addresses ports (sockets)
Port and Sockets
 Previously seen from the application layer.
 Port numbers 16 bits, 0->65535.
 Port numbers 0->1023 are well known port
numbers, and are restricted.
 Why does a transport header have both
source and destination port numbers?
 Surely the destination port number alone is
sufficient to identify the recipient?
Simple Example
 Client is assigned
source port: x
some random unused host A dest. port: 25 server B
port X by its host.
 The SMTP server source port:25
runs on well known dest. port: x

port 25.
 Reply is to destination port use: simple smtp

port X, with src port

25
 What About Two Clients?
source port: x Web client
host A dest. port: 25 server B host C

source port:25
dest. port: x
Source IP: C Source IP: C
Dest IP: B Dest IP: B
source port: y source port: x
port use: simple smtp dest. port: 80 dest. port: 80

Source IP: A
Dest IP: B Web
Web client source port: x server B
host A dest. port: 80
port use: Web server
Ports and Sockets - Detail
 Server listens on a
socket for a listener
connection thread worker
 Connect request worker
causes new socket on
same port
 Server uses new TCP
thread to service
server socket
connection socket
port
UDP
 “best
effort” service,  Why have UDP?
segments may be:  no connection
– lost establishment (which
– delivered out of order can add delay)
 connectionless:  simple: no connection
– no handshaking state at sender, receiver
between sender,  small segment header
receiver  no congestion control:
– each segment handled UDP can blast away as
independently fast as desired
More on UDP includes
header
 UDP used for
– DNS src port no dest port no
– SNMP length checksum
– Multimedia streaming
 Loss tolerant
 Rate sensitive
data
 reliable transfer
– add reliability at
application layer 32 bits
UDP Checksum
Goal: detect “errors” in transmitted segment
Sender
 treat segment contents as
sequence of 16-bit integers
 checksum: addition (1’s
complement sum) of
segment contents
 sender puts checksum value
into UDP checksum field
Receiver
 compute checksum of
received segment
 check if computed
checksum equals
checksum field value:
– NO - error detected
– YES - no error
detected. But maybe
errors nonetheless?
TCP Socket Structure
Client Server
process process

3-way handshake “public”

client socket
socket
stream data “connection”
socket
TCP Steps
Client
Server (on hostId)
Create socket
Create public socket with Connect to hostId, port x
port = x
Send request on client socket
Wait for connection
create connection socket

Read request from connection

socket Read reply from client socket
Write reply to connection socket Close client socket
 Java server (TCP)
import java.io.*;
import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception

{
String clientSentence;
Create String capitalizedSentence;
welcoming socket
ServerSocket welcomeSocket = new ServerSocket(6789);
at port 6789
while(true) {
Wait, on welcoming
socket for contact Socket connectionSocket = welcomeSocket.accept();
by client
BufferedReader inFromClient =
Create input new BufferedReader(new
stream, attached InputStreamReader(connectionSocket.getInputStream()));
to socket
 Java server (TCP), cont
Create output
stream,
attached DataOutputStream outToClient =
to socket new DataOutputStream(connectionSocket.getOutputStream());
Read in line
from socket clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

Write out line
outToClient.writeBytes(capitalizedSentence);
to socket
}
}
} End of while loop,
loop back and wait for
another client connection
 Example: Java client (TCP)
import java.io.*;
import java.net.*;
class TCPClient {

public static void main(String argv[]) throws Exception

{
String sentence;
String modifiedSentence;
Create
input stream BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));
Create
client socket, Socket clientSocket = new Socket("hostname", 6789);
connect to server
Create DataOutputStream outToServer =
output stream new DataOutputStream(clientSocket.getOutputStream());
attached to socket
 Example: Java client (TCP), cont.
Create BufferedReader inFromServer =
input stream new BufferedReader(new
attached to socket InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();
Send line
to server outToServer.writeBytes(sentence + '\n');

Read line modifiedSentence = inFromServer.readLine();

from server
System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

}
}
The End.
 We learned about:
– the Socket API connecting them to the transport layer.
 reliable (TCP) vs. unreliable (UDP) msg transfer

 Thank you for your attention !

Sources
 For the preparation of this lectures a lot of
sources where used – my special thanks go
to :
– Univ. Auckland
– Univ. California – San Diego (UCSD)
– Univ. Hongkong
– … many others …