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 [Link](dp1);
‹ Constructing a receiving packet: [Link](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, [Link], } finally {
address, port);
[Link]();
}

Datagram Contents IP Broadcasting

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

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

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

‹ Packets are only delivered ‹ ‘Distributors’ are multicast-
multicast- ‹ Application can specify the IP
to subscribers capable routers time-
time-to-
to-live (TTL) value
‹ Subscribers must explicitly ‹ They construct a multicast ™ how far multicast packets should
travel
request packets from the local distribution tree
™ 0: to the local host
distributors ‹ Each multicast distribution tree is ™ 1: on the local LAN
‹ No duplicate packets are sent represented by a pseudo-
pseudo-IP ™ 2–31:
31: to the local site (network)
down the same distribution path address (multicast IP address, ™ 32–
32–63:
63: to the local region
‹ Original ‘publisher’ does not need class D address) ™ 64–
64–127:
127: to the local continent
to know all subscribers ™ [Link]–
[Link]–[Link] ™ 128–
128–254:
254: deliver globally
™ some addresses are reserved
‹ Receiver-
Receiver-controlled distribution ™ local applications should use
[Link]–
[Link]–[Link]
‹ 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 =
[Link](GROUP_ADDRESS);
[Link](GROUP_ADDRESS);
‹ Older routers do not support multicasting [Link](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, [Link](dp);
Mbone)
Mbone) ‹ Finally the receiver leaves the group and closes the socket:
Participant’s local router has to be multicast-
[Link](group);
™ multicast-capable
[Link]();

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); [Link](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, [Link]);
try {
[Link], GROUP_ADDRESS, PORT); [Link](packet);
[Link](packet); return [Link]();
} catch (IOException e) { /* Sending failed. */ } catch (IOException e) { /* Receiving failed. */ }
} } return null;
}
public void finalize() { public void finalize() {
if (socket != null) [Link]();
if (socket != null) { [Link](); [Link](); }
[Link](); [Link]();
} } } }

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
Put into a Two-
Two-Player LAN?
‹ Logical connections ‹ Distributed Interactive Simulation ‹ Assumptions:
(DIS) protocol data unit (PDU): ™ sufficient processor power
™ how the messages flow LAN
144 bytes (1,152 bits) ™ no other network usage
‹ Graphics: 30 frames/second ™ a mix of player types
‹ Physical connections
‹ PDU rates
™ the wires between the ™ aircraft 12 PDU/second ⇒ LAN: 8,680 packets/second
computers ™ ground vehicle 5 PDU/second fully articulated humans + firing =
™ the limiting factor in ™ weapon firing 3 PDU/second 263 humans
communication architecture aircrafts + firing = 578 aircrafts
p1 p2 ™ fully articulated human 30
ground vehicles + firing = 1,085
design 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

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