Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706
Home Page
Data Communications and Networks I • 4003-420-01/4005-740-01 • Fall Quarter 2012
Course Page

4003-420-01/4005-740-01 Data Communications and Networks I
Module 8. Network Application Design -- Lecture Notes

Prof. Alan Kaminsky -- Fall Quarter 2012
Rochester Institute of Technology -- Department of Computer Science

DayTime Application Version 1
DayTime Application Version 2
DayTime Application Version 3
Password Crack Application Version 1
Password Crack Application Version 2
Password Crack Application Version 3
Network Go Game Version 1
Network Go Game Version 2
Network Go Game Version 3
Network Go Game Version 4
IP Multicasting
Network Go Game Version 5
Network Go Game Version 6

DayTime Application Version 1

DayTime Application Version 2

  • Client program -- Class DayTime [source]

  • Server program -- Class DayTimeServer [source]
    • Multithreaded server
    • Server creates and starts a new thread for each client socket connection

DayTime Application Version 3

Password Crack Application Version 1

The Password Crack Application does a brute force attack to crack a password. The MD5 hash of the password is known; MD5 is a cryptographic one-way hash function. It is also known that the password consists of anywhere from 1 to 5 lower-case letters (a through z). The user specifies the password's MD5 hash as a 32-hexadecimal-digit number. The program tries every possible password until it finds one with that hash. The program then displays the password.

The Password Crack Application Version 1 runs in a single process. However, it is designed to be "network ready" -- able to be changed to a client-server network application with minimal effort. The application is designed using the well-known Model-View-Controller (MVC) and Observer patterns.

(click for larger image)

Source code:

Password Crack Application Version 2

The Password Crack Application Version 2 runs in two processes. The server process contains the model. The client process contains the view. The processes communicate over the network. The application is still designed using the well-known Model-View-Controller (MVC) and Observer patterns. The application also uses the Network Proxy pattern.

(click for larger image)

The Application Layer protocol for the Password Crack Application Version 2 uses TCP at the Transport Layer. Network messages use a binary encoding, are written to the socket using a DataOutputStream, and are read from the socket using a DataInputStream.

Server-to-client messages are encoded as follows. Each message corresponds to a method in interface ModelListener.

ModelListener method Message encoding
started() 'G' (1 byte)
progress (percent) 'P' (1 byte)
Progress (1 byte)
found (password) 'F' (1 byte)
Password (UTF-8 string)
stopped() 'S' (1 byte)

Client-to-server messages are encoded as follows. Each message corresponds to a method in interface ViewListener.

ViewListener method Message encoding
start (hash) 'G' (1 byte)
Hash (16 bytes)
stop() 'S' (1 byte)

The Password Crack Application Version 2 is a multi-session single-client network application. The server supports multiple sessions, but each session is associated with just a single client. On the server, a "session" consists of the model object plus the view proxy object with its internal socket and reader thread. When a client sets up a connection to the server, the server creates a brand-new session and hooks up the client to that session.

(click for larger image)

Source code:

Password Crack Application Version 3

The Password Crack Application Version 3 runs in two processes. The server process contains the model. The client process contains the view. The processes communicate over the network. The application is still designed using the well-known Model-View-Controller (MVC) and Observer patterns. The application also uses the Network Proxy pattern.

(click for larger image)

The Application Layer protocol for the Password Crack Application Version 3 uses TCP at the Transport Layer. Network messages use an object encoding, are written to the socket using an ObjectOutputStream, and are read from the socket using an ObjectInputStream.

Like the Password Crack Application Version 2, the Password Crack Application Version 3 is a multi-session single-client network application. The server supports multiple sessions, but each session is associated with just a single client. On the server, a "session" consists of the model object plus the view proxy object with its internal socket and reader thread. When a client sets up a connection to the server, the server creates a brand-new session and hooks up the client to that session.

(click for larger image)

Source code:

Network Go Game Version 1

Go is played on a 19×19 grid. Colored markers are placed on the grid intersections. For further information, see these Wikipedia articles:

The Network Go Game allows any number of players to play Go and similar games with each other from their own PCs over the network. All players see the same Go board. Each player chooses a color for his or her markers. Left-clicking on an intersection places a marker of the player's color at that point (replacing any existing marker). Right-clicking on an intersection removes the marker if any. Clicking the "Clear Board" button clears the whole board. Clicking the color swatch next to the "Clear Board" button pops up a dialog to let the player choose the marker color. Closing the window removes the player from the game; however, the player's markers if any remain on the board. The computer is not a player in the game and does not enforce any rules, taking turns, etc.; the computer is just a glorified game board.

Unlike the Password Crack Application, the Network Go Game Version 1 is a single-session multi-client network application. The server supports just one session, and all clients are part of that one session. On the server, the "session" consists of the model object plus all the view proxy objects with their internal sockets and reader threads. When a client sets up a connection to the server, the server hooks up the client to the one session.

(click for larger image)

However, there's a problem with the design so far. To draw the display, the view needs to query the model to determine whether each of the 361 intersections has a marker and what the marker's color is. But the model is in the server, and we don't want all that network traffic to query the model every time we draw the display. Instead, we'll put a clone of the model in each client. A client's view reports user interface actions to the server's model. The server's model updates the model clones in all the clients, the model clones inform their views, and the views query the client-local model clones to redraw their displays.

(click for larger image)

The Application Layer protocol for the Network Go Game Version 1 uses TCP at the Transport Layer. Network messages use a binary encoding, are written to the socket using a DataOutputStream, and are read from the socket using a DataInputStream.

Client-to-server messages are encoded as follows. Each message corresponds to a method in interface ViewListener.

ViewListener method Message encoding
addMarker (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
removeMarker (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
clearBoard() 'C' (1 byte)

Server-to-client messages are encoded as follows. Each message corresponds to a method in interface ModelListener.

ModelListener method Message encoding
markerAdded (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
markerRemoved (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
boardCleared() 'C' (1 byte)

Source code:

Network Go Game Version 2

Unlike the Network Go Game Version 1, the Network Go Game Version 2 is a multi-session multi-client network application. The server supports multiple sessions, and each client is part of one session. On the server, each "session" consists of the model object plus all the view proxy objects with their internal sockets and reader threads. When a client sets up a connection to the server, the server hooks up the client to the Session Manager. The first message the client sends tells the server which session the client wants to join; the session name is specified on the client command line. The Session Manager processes this message by creating the session (if it does not already exist) and hooking up the client to the session. Once created, a session persists in the server forever.

(click for larger image)

The Application Layer protocol for the Network Go Game Version 2 uses TCP at the Transport Layer. Network messages use a binary encoding, are written to the socket using a DataOutputStream, and are read from the socket using a DataInputStream.

Client-to-server messages are encoded as follows. Each message corresponds to a method in interface ViewListener.

ViewListener method Message encoding
join (session) 'J' (1 byte)
Session name (UTF-8 string)
addMarker (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
removeMarker (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
clearBoard() 'C' (1 byte)

Server-to-client messages are encoded as follows. Each message corresponds to a method in interface ModelListener.

ModelListener method Message encoding
markerAdded (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
markerRemoved (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
boardCleared() 'C' (1 byte)

Source code:

Network Go Game Version 3

The Network Go Game Version 3 is the same as Version 2, except a different transport layer protocol is used.

(click for larger image)

The Application Layer protocol for the Network Go Game Version 3 uses UDP at the Transport Layer. Each network message is sent as a UDP datagram. Messages use a binary encoding, are written to the datagram payload using a DataOutputStream, and are read from the datagram payload using a DataInputStream. The same encoding is used in Versions 2 and 3.

Client-to-server messages are encoded as follows. Each message corresponds to a method in interface ViewListener.

ViewListener method Message encoding
join (session) 'J' (1 byte)
Session name (UTF-8 string)
addMarker (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
removeMarker (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
clearBoard() 'C' (1 byte)

Server-to-client messages are encoded as follows. Each message corresponds to a method in interface ModelListener.

ModelListener method Message encoding
markerAdded (r, c, color) 'A' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
Color (integer, 4 bytes)
markerRemoved (r, c) 'R' (1 byte)
Row r (integer, 1 byte)
Column c (integer, 1 byte)
boardCleared() 'C' (1 byte)

Source code:

The Network Go Game Version 3 does not address the following issues:

  1. UDP does not guarantee reliable delivery or ordering of datagrams. Messages may be lost or received in a different order than they were sent.

  2. The server does not detect when the user closes the window. Once created in the server, a ViewProxy stays around forever, even if the associated client goes away.

  3. Once created in the server, a Go session stays around forever, even if all of the session's clients go away.

Network Go Game Version 4

The Network Go Game Version 4 uses a peer-to-peer (P2P) architecture rather than a client-server architecture. The two players agree to use a certain host name and port number. Each player runs the same peer program. One peer (the first one to run) listens for a socket connection on the given host and port. The other peer (the second one to run) connects to the first peer at the given host and port. The first peer acts as the "server" for the game; it creates the same objects as the Version 2 server, plus a View object. The second peer acts as the "client" for the game; it creates the same objects as the Version 2 client. (Although Version 4 supports only two players, it could be easily changed to support more than two players by allowing the "server" to accept connections from additional peers, as in Version 2.)

(click for larger image)

The Application Layer protocol for the Network Go Game Version 4 uses TCP at the Transport Layer and is identical to Version 2.

Source code:

IP Multicasting

  • RFC 1112

  • Multicast group IP addresses

  • Multicast group communication
    • An IP packet sent to a multicast group IP address is received by all hosts that are members of that multicast group

  • Internet Group Management Protocol (IGMP)
    • IGMP v2: RFC 2236 (1997)
    • IGMP v3: RFC 3376 (2002)
    • A way for a host to inform its Internet gateway (router) of the multicast group(s) to which the host belongs
    • Join(group_address) -- Router starts forwarding multicast group traffic to the host
    • Leave(group_address) -- Router stops forwarding multicast group traffic to the host

  • IP multicasting over an Ethernet LAN
    • See RFC 1112, Section 6.4
    • IP address (hex) = Ey xx xx xx
    • Ethernet address (hex) = 01 00 5E xx xx xx
    • This is an Ethernet group address
    • When the host joins multicast group (Ey xx xx xx), the host also programs its Ethernet interface to accept frames from Ethernet group address (01 00 5E xx xx xx)
    • Note that multiple multicast group addresses map to the same Ethernet group address -- higher protocol layers must distinguish IP datagrams for different multicast groups if necessary

  • LAN broadcast using IP multicast
    • As a consequence of the IP-Ethernet multicast address mapping, all hosts on the same Ethernet LAN in the same IP multicast group will receive each other's IP multicast packets, even if the router does not support multicasting
    • This is a convenient way to get "selective broadcasting" within a LAN
    • Hosts can send messages to each other without needing to know each other's IP addresses, just the well-known multicast group IP address

  • Java support for IP multicasting
    • Class java.net.MulticastSocket

Network Go Game Version 5

Like Version 4, the Network Go Game Version 5 uses a peer-to-peer (P2P) architecture rather than a client-server architecture. However, the network communication uses multicast datagrams instead of point-to-point sockets. Each peer sends UDP datagrams to and receives UDP datagrams from an agreed-upon multicast group IP address (default: 239.255.0.1) and port number (default: 56789). Whenever any peer in the multicast group sends a datagram, all the peers in the multicast group receive that datagram. Each peer has its own model object and view object. User interface actions update the peer's model object; a message with the new state of the model is then multicast to all peers in the multicast group.

(click for larger image)

The Application Layer protocol for the Network Go Game Version 5 uses UDP at the Transport Layer. Each network message is sent as a UDP datagram. Messages use a binary encoding, are written to the datagram payload using a DataOutputStream, and are read from the datagram payload using a DataInputStream. Each message corresponds to a method in interface ModelListener. The "unique ID" uniquely identifies the peer that sent the message.

ModelListener method Message encoding
playerJoined() Opcode = 0 (integer, 1 byte)
Unique ID (long, 8 bytes)
boardChanged (board) Opcode = 1 (integer, 1 byte)
Unique ID (long, 8 bytes)
For each non-empty spot on the board:
    Row index (integer, 1 byte)
    Column index (integer, 1 byte)
    Color (integer, 4 bytes)
End-of-board sentinel = −1 (integer, 1 byte)

Source code:

Notes:

  • Unlike all the preceding programs, the users don't have to specify a host and port.

  • Different game sessions are associated with different multicast group IP addresses and/or port numbers.

  • Multicast datagrams travel throughout the local network (wired Ethernet switch or wireless Ethernet access point). However, routers typically do not forward multicast datagrams. Thus, only users on the same local network can participate in a game session.

  • As presently designed, the game does not deal with these situations:
    • Two users make changes to the board simultaneously.
    • Some processes receive multicast datagrams in a different order from other processes.
    • Some processes fail to receive a multicast datagram.

Network Go Game Version 6

Like Version 5, the Network Go Game Version 6 uses a peer-to-peer (P2P) architecture and communicates using multicast datagrams. Version 6 adds two features:

  1. The Go board state includes a logical clock. The logical clock counts the number of changes that have been made to the board state since the beginning of the game. When a peer receives a board state message, it will update its own board state only if the logical clock in the message is greater than the peer's own logical clock. If the logical clocks are the same, the peer will update its own board state only if the unique ID in the message is greater than the peer's own unique ID. The logical clock solves two of the issues with Version 5:
    • Two users make changes to the board simultaneously.
    • Some processes receive multicast datagrams in a different order from other processes.

  2. Each peer sends a message with the current board state periodically, even if the board state has not changed. The time delay between such periodic reports is randomized to try to prevent message collisions. The periodic board state messages solve the remaining issue with Version 5:
    • Some processes fail to receive a multicast datagram.

(click for larger image)

The Application Layer protocol for the Network Go Game Version 6 uses UDP at the Transport Layer. Each network message is sent as a UDP datagram. Messages use a binary encoding, are written to the datagram payload using a DataOutputStream, and are read from the datagram payload using a DataInputStream. Each message corresponds to a method in interface ModelListener. The "unique ID" uniquely identifies the peer that sent the message.

ModelListener method Message encoding
playerJoined() Opcode = 0 (integer, 1 byte)
Unique ID (long, 8 bytes)
boardChanged (board) Opcode = 1 (integer, 1 byte)
Unique ID (long, 8 bytes)
Logical clock (long, 8 bytes)
For each non-empty spot on the board:
    Row index (integer, 1 byte)
    Column index (integer, 1 byte)
    Color (integer, 4 bytes)
End-of-board sentinel = −1 (integer, 1 byte)

Source code:

Data Communications and Networks I • 4003-420-01/4005-740-01 • Fall Quarter 2012
Course Page
Alan Kaminsky • Department of Computer Science • Rochester Institute of Technology • 4486 + 2220 = 6706
Home Page
Copyright © 2012 Alan Kaminsky. All rights reserved. Last updated 23-Oct-2012. Please send comments to ark­@­cs.rit.edu.