Special Course on Networked Virtual January 30, 2004

Environments

Internet Protocol (IP) TCP versus UDP

‹ Low-
Low-level protocols used by hosts and routers Transmission Control Protocol User Datagram Protocol
‹ Guides the packets from source to destination host (TCP/IP) (UDP/IP)
‹ Point-
Point-to-
to-point connection ‹ Lightweight data transmission
‹ Hides the transmission path
‹ Reliable transmission using ‹ Differs from TCP
™ phone lines, LANs, WANs, wireless radios, satellite links, carrier
carrier
acknowledgement and ™ connectionless transmission
pigeons,…
retransmission ™ ‘best-
‘best-efforts’ delivery
‹ Applications rarely use the IP directly but the protocols that are
are Stream-
Stream-based data semantics
‹ ™ packet-
packet-based data semantics
written on top of IP ‹ Big overhead ‹ Packets are easy to process
™ Transmission Control Protocol (TCP/IP) ™ data checksums ‹ Transmission and receiving
™ User Datagram Protocol (UDP/IP) ‹ Hard to ‘skip ahead’ immediate
‹ No connection information for
each host in the operating system
‹ Packet loss can be handled

UDP and Datagrams in Java Datagram Example

‹ DatagramSocket can both send and receive packets try {
™ no server sockets because there is no need to establish a connection
connection
socket = new DatagramSocket(PORT);
DatagramSocket(PORT);
‹ DatagramPacket includes all the data to be sent/received
™ maximum size 64 kB socket.receive(dp1);
‹ Constructing a receiving packet: socket.send(dp2);
byte[]
byte[] buffer = new byte[CAPACITY];
byte[CAPACITY];
DatagramPacket dp1 =
} catch (SocketException e) {
new DatagramPacket(buffer,
DatagramPacket(buffer, CAPACITY); // Could not open the socket.
‹ Constructing a packet to send: } catch (IOException e) {
byte[] message; // The bytes to send.
byte[]
DatagramPacket dp2 = // Problems with communication.
new DatagramPacket(message,
DatagramPacket(message, message.length, } finally {
address, port);
socket.close();
}

Datagram Contents IP Broadcasting

‹ Sender’s address: ‹ Using a single UDP/IP socket, the
same packet can be sent to
InetAddress addr = dp.getAddress(); multiple destinations by repeating
‹ Sender’s port: the send call
™ ‘unicasting’
int port = dp.getPort(); ™ great bandwidth is required
‹ Packet payload size: ™ each host has to maintain a list of
other hosts
int size = dp.getLength();
‹ Packet payload data: ‹ IP broadcasting allows a single
transmission to be delivered to all
byte[]
byte[] data = dp.getData(); hosts on the network
™ a special bit mask of receiving
hosts is used as a address
‹ With UDP/IP, the data is only
delivered to the applications that
are receiving on a designated port
‹ Broadcast is expensive
™ each host has to receive and
process every broadcast packet
‹ Only recommended (and only
guaranteed) on the local LAN
‹ Not suitable for Internet-
Internet-based
applications

Jouni Smed 1
Special Course on Networked Virtual January 30, 2004
Environments

IP Multicasting 1 (3) IP Multicasting 2 (3)

‹ Packets are only delivered
to subscribers
‹ Subscribers must explicitly
request packets from the local
distributors
‹ No duplicate packets are sent
down the same distribution path
‹ Original ‘publisher’ does not need
to know all subscribers
‹ Receiver-
Receiver-controlled distribution
‹ ‘Distributors’ are multicast-
multicast- ‹ Application can specify the IP
capable routers time-
time-to-
to-live (TTL) value
‹ They construct a multicast ™ how far multicast packets should
travel
distribution tree
™ 0: to the local host
‹ Each multicast distribution tree is ™ 1: on the local LAN
represented by a pseudo-
pseudo-IP ™ 2–31:
31: to the local site (network)
address (multicast IP address, ™ 32–
32–63:
63: to the local region
class D address) ™ 64–
64–127:
127: to the local continent
™ 224.0.0.0–
224.0.0.0–239.255.255.255 ™ 128–
128–254:
254: deliver globally
™ some addresses are reserved
™ local applications should use
239.0.0.0–
239.0.0.0–239.255.255.255
‹ Address collisions possible
™ Internet Assigned Number
Authority (IANA)

IP Multicasting 3 (3) Multicasting in Java

‹ Provides desirable network efficiency ‹ Uses DatagramPacket as in UDP
‹ Allows partitioning of different types of data by using multiple ‹ Sender sends datagram packets to a multicast address
multicast addresses ‹ Receiver joins the multicast address (group):
‹ NVE participants can announce their presence by using
MulticastSocket socket =
new MulticastSocket(PORT);
MulticastSocket(PORT);
application’s well-
well-known multicast address InetAddress group =
InetAddress.getByName(GROUP_ADDRESS);
InetAddress.getByName(GROUP_ADDRESS);
‹ Older routers do not support multicasting socket.joinGroup(group);
‹ Multicast-
Multicast-aware routers communicate directly by ‘tunneling’ ‹ Packets are received like normal UDP datagrams:
data past the non-
non-multicast routers (Multicast Backbone, socket.receive(dp);
Mbone)
Mbone) ‹ Finally the receiver leaves the group and closes the socket:
Participant’s local router has to be multicast-
socket.leaveGroup(group);
™ multicast-capable
socket.close();

Multicast Example: Sender Multicast Example: Receiver

class MulticastSender { class MulticastReceiver {
private DatagramSocket socket; private MulticastSocket socket;
public MulticastReceiver() {
public MulticastSender() { try {
try { socket = new MulticastSocket(PORT);
socket = new DatagramSocket(PORT); socket.joinGroup(GROUP_ADDRESS);
} catch (SocketException e) { /* Construction failed. */ } catch (IOException e) { /* Joining failed. */ }
} } }
public byte[] receive() {
public void send(byte[] data) { byte[] buffer = new byte[BUFFER_SIZE];
try { DatagramPacket packet =
Datagram packet = new DatagramPacket(data, new DatagramPacket(buffer, buffer.length);
try {
data.length, GROUP_ADDRESS, PORT); socket.receive(packet);
socket.send(packet); return packet.getData();
} catch (IOException e) { /* Sending failed. */ } catch (IOException e) { /* Receiving failed. */ }
} } return null;
}
public void finalize() { public void finalize() {
if (socket != null) socket.close();
if (socket != null) { socket.leaveGroup(); socket.close(); }
super.finalize(); super.finalize();
} } } }

Jouni Smed 2
Special Course on Networked Virtual January 30, 2004
Environments

Selecting an NVE Protocol 1 (4) Selecting an NVE Protocol 2 (4)

‹ Multiple protocols can be used in a single system ‹ Using UDP/IP

‹ Not which protocol should I use in my NVE but which

™ lightweight
™ offers no reliability nor guarantees the order of packets
protocol should I use to transmit this piece of information?
information?
™ packets can be sent to multiple hosts
™ deliver time-
time-sensitive information among a large number of hosts
‹ Using TCP/IP
™ reliable data transmission between two hosts ™ more complex services have to be implemented in the application
~ serial numbers, timestamps
™ packets are delivered in order, error handling
™ recovery of lost packets
™ relatively easy to use
~ positive acknowledgement scheme
~ negative acknowledgement scheme
™ point-
point-to-
to-point limits its use in large-
large-scale NVEs  more effective when the destination knows the sources and their frequency

™ bandwidth overhead ™ transmit a quench packet if packets are received too often

Selecting an NVE Protocol 3 (4) Selecting an NVE Protocol 4 (4)

‹ Using IP broadcasting ‹ Using IP multicasting
™ design considerations similar to (unicast
(unicast)) UDP/IP ™ provides a quite efficient way to transmit information among a large
™ limited to LAN number of hosts
™ not for NVEs with a large number of participants ™ information delivery is restricted
~ time-
time-to-
to-live
™ to distinguish different applications using the same port number (or
multicast address): ~ group subscriptions

~ Avoid the problem entirely: assign the necessary number ™ preferred method for large-
large-scale NVEs
~ Detect conflict and renegotiate: notify the participants and direct
direct them to ™ how to separate the information flows among different multicast
migrate a new port number groups
~ Use protocol and instance magic numbers: each packet includes a magic ~ a single group/address for all information
number at a well-
well-known position ~ several multicast groups to segment the information
~ Use encryption

Example: How May Players Can We

Communication Architectures
‹ Logical connections
™ how the messages flow
‹ Physical connections
™ the wires between the
computers
™ the limiting factor in
communication architecture
design
Put into a Two-
Two-Player LAN?
‹ Distributed Interactive Simulation ‹ Assumptions:
(DIS) protocol data unit (PDU): ™ sufficient processor power
LAN
144 bytes (1,152 bits) ™ no other network usage
‹ Graphics: 30 frames/second ™ a mix of player types
‹ PDU rates
™ aircraft 12 PDU/second ⇒ LAN: 8,680 packets/second
™ ground vehicle 5 PDU/second fully articulated humans + firing =
™ weapon firing 3 PDU/second 263 humans
aircrafts + firing = 578 aircrafts
p1 p2 ™ fully articulated human 30
ground vehicles + firing = 1,085
PDU/second
vehicles
Two players on a LAN ‹ Bandwidth ‹ Typical NPSNET-
NPSNET-IV DIS battle
™ Ethernet LAN 10 Mbps
™ limits to 300 players on a LAN
™ modems 56 Kbps
™ processor and network
limitations

Jouni Smed 3
Special Course on Networked Virtual January 30, 2004
Environments

Example (cont’d)
⇒ Modem: 48 packets/second
fully articulated humans + firing = 1
human
aircrafts + firing = 3 aircrafts
ground vehicles + firing = 6 vehicles
‹ Redesign packets
™ size 22%, 32 bytes
⇒ Modem: 218 packets/second
fully articulated humans + firing = 7
human
aircrafts + firing = 14 aircrafts
ground vehicles + firing = 27 vehicles
Multiplayer Client-
Client-Server Systems:
Logical Architecture
‹ In a two-
two-player NVE on a LAN, ‹ Client-
Client-server system
™ each player sends packets to
the protocol selection (TCP, UDP,
other players via a server
broadcast,...) hardly matters
‹ Server slows down the message
‹ As the number of live or Communication
delivery
autonomous players increase an paths
‹ Benefits of having a server
efficient architecture becomes ™ no need to send all packets to all
more important players
™ compress multiple packets to a
single packet
™ smooth out the packet flow
p1 p2 pn
™ reliable communication without
the overhead of a fully connected
Multiplayer client-server - logical architecture
NVE
™ administration

Multiplayer Client-
Client-Server Systems: Physical Architecture Can Match
Physical Architecture (on a LAN) the Logical Architecture
‹ All messages in the same wire Server
‹ Server has to provide some added-
added-value function
™ collecting data
™ compressing and redistributing information Phone lines
™ additional computation

LAN

p1 p2 pn
p1 p2 pn Server Multiplayer client-server -
Multiplayer client-server - physical architecture on a LAN physical architecture with phone lines

Multiplayer Client-
Client-Server, p1,1 p1,2 p1,n

Peer-to-Peer Architectures
Server 1

with Multiple-
Multiple-Server Architectures
Server 2 Server 3

p2,1 p2,2 p2,n p3,1 p3,2 p3,n

‹ Players can locate in the same ‹ In the ideal large-

large-scale NVE
LAN
place in the NVE, but reside on design, avoid having servers at all
different servers ™ eventually we cannot scale out
p1,1 p1,2 p1,n
™ Real World ≠ Virtual World ™ a finite number of players
‹ Server-
Server-to-
to-server connections Server 1 ‹ Design goal p1 p2 pn
transmit the world state ™ peer-
peer-to-
to-peer communication Peer-to-peer on a LAN

information ™ scalable within resources

Server 2 Server 3
™ WAN, LAN ‹ Peer-
Peer-to-
to-peer: communication goes p1 p2

‹ Each server serves a number of directly from the sending player to

client players the receiving player (or a set of
™ LAN, modem, cable modem
p2,1 p2,2 p2,n p3,1 p3,2 p3,n
them) p3 p4

‹ Scalability

Jouni Smed 4
Special Course on Networked Virtual January 30, 2004
Environments

Peer-to-Peer with Multicast Basic Architecture Components

Network
‹ For a scalable NVE on a LAN, use
multicast
‹ To utilize multicast, assign packets AOIM 1 AOIM 1 AOIM 1
to proper multicast groups
‹ Area-
Area-of-
of-interest management
™ assign outgoing packets to the p1 p2 pn
right groups AOIM software layer
™ receive incoming packets to the
appropriate multicast groups
™ keep track of available groups
™ even out stream information

(Hint: This would be a good time to browse the additional literature.)

Jouni Smed 5