CS 102 (Spring 2003)
Lab 5a: IM Bot (Part a)

Author: Ron K. Cytron and David Jurgens
Lab Assigned Design Due
(In class)
10 AM
(In Lab)
(In Lab)
Lab Due
(In lab)
18 Mar 19 Mar 26 Mar 26 Mar


Programs can communicate across the Internet using sockets, but the programs must agree on a protocol for such communication. In this lab, you design and implement a low-level package that implements the FLAP protocol. Using that package, you will write a client and server to initiate and verify an AIM session, respectively.

The entire work of this lab is to be carried out in teams of two people. The design is collaborative, and the resulting pieces are split for implementation among the team members. The client and server are also split, with an integrating exercise to test both parts.


By the end of this lab, you should

Before starting:

[[[ Download PC zip ]]]
Zip includes:

Overview of FLAP

Every frame is of the following form:
Byte offset Length (bytes) What
0 1 An asterisk

The asterisk is transmitted as a byte, but you can cast it to a char and then compare it with an asterisk to see if it is what you expect. Why do all frames begin this way? It's so you can catch framing errors. If you read too much or too little in the previous frame, then the next frame (probably) won't begin with the asterisk you expect.

1 1 Frame type

For our application, this will be an integer in the set {1, 2, 4, 5}, and it indicates the type of the frame, as described in the TOC document.

2 2 Sequence Number

This is an unsigned, 2-byte integer that is managed separately in each direction. You should make sure to increment this number for every frame you send to the server; the same is true going from server to client.

4 2 Payload Length

This is the length in bytes of the rest of this frame. Thus, this is an unsigned, 2-byte integer. You must make sure to consume exactly the right number of bytes for the payload, or you will experience a framing error.

Payload for Signon Frame (Frame Type = 1)

Note: An abbreviated form of this frame is sent from Host to Client, as indicated in the table below.

Byte offset Length (bytes) What
6+0 4 FLAP Version Number (Host « Client)

This is a four-byte, unsigned integer that is expected to be 1 in both directions.

6+4 2 TLV Tab (Client ® Host)

This is a 2-byte unsigned integer that is expected to be 1. This field is not transmitted from host to client.

6+6 2 User Name Length (Client ® Host)

This is the length of the normalized user name that comes next. In a sense this is redundant, since the length of the entire frame is given up front, but this is what is required and probably simplifies life for the server. This field is not transmitted from host to client.

6+8 Payload Length - 8 User Name (Client ® Host)

The rest of the frame contains the normalized user name. Normalized means no spaces anywhere, and all characters in lower-case form. Placing the user name in this canonical form simplfies life for the server. This field is not transmitted from host to client.

Payload for Data Frame (Frame Type = 2)

Byte offset Length (bytes) What
6+0 Payload Length Data

The length of the data is given in the header. The data is a sequence of characters that is null-terminated ('\0') from the client to the server, but not in the other direction. The length includes the null character if it is present.

Payload for KeepAlive Frame (Frame Type = 5)

Byte offset Length (bytes) What
6+0 4 I'm not sure what this is. If you figure it out please let me know. It seems always to have the value of 50.

Design principles

What to do in Lab Section

What to turn in:

  1. A code cover sheet.
  2. The JavaDoc of your design
  3. Any Java files you have created or modified
  4. Screen shots showing the communication taking place between client and server.

Last modified 16:28:45 CST 25 March 2003 by Ron K. Cytron