Overview:

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.

Goals:

• Understand how to send binary data using a sccket.
• Understand a simple protocol (FLAP).
• Understand how an AIM session is established.
• Appreciate the value of team programming.

Before starting:

• Read this entire document before you start.
• Read the lecture materials on sockets.
  • Sun tutorial on Sockets
  • JavaWorld article
  • Sun tutorial on networking (optional)
• Check out the following that simplify network I/O
  • DataInputStream decorator of an InputStream
  • DataOutputStream decorator of an OutputStream
  • Socket
  • ServerSocket
• Read theTOC protocol document in several convenient forms.
• See the following classes to understand how the Visitor pattern applies:
  • flap/Visitable
  • flap/Visitor
  • flap/Frame
  • flap/PrntVisitor

Overview of FLAP

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

• The objects you are given for this lab represent Frame objects. As such, they are unware that they might be transmitted over a network.

  Try to keep separate the concerns of the frames' representation from their transmission.

• The transmission varies depending on the direction. From client to server, more is generally sent. There is more transmitted for a SignonFrame and the DataFrame objects have their strings null-terminated. From the server to the client, less is sent.

  Try not to combine too much in one object.

  An object that must handle transmission in either direction is more complicated than two objects, each of which handles just one direction.

• Because you will be performing network I/O, there are many methods that can throw exceptions. It may be the case that the first thing you write or read will cause a problem, but you really don't expect that if one write succeeds that the next one will fail.
  • Avoid code that is littered with try { } .. catch ( ) blocks.
  • Avoid placing tons of code within any try { } .. catch ( ) block.
  • Don't catch errors only to hide them.

  Instead, consider using a helper method that does all the work, each part of which can throw an exception. Then, have that helper method advertize that it throws the exception (java.io.IOException in this case). Within the helper method, no checking is necessary. One check is necessary at the call to the helper method. At that check, don't just print out something. Either rethrow the exception as an Error or take corrective action (may not be possible).

What to do in Lab Section

• Unzip the zip for this assignment, which will create the beginnings of your flap package.
• Find out the IP address of the PC that will act as your server:
  • From Start, click Run, and then type "command" or "cmd" From that window, type

    ipconfig /all

    and it should show you the domain name of the machine.
  • Or, look under the table at the PC box and it has a label on it, such as pc123 in which case its IP address is probably pc123.cec.wustl.edu.
• Decide how you will read and write the various Frame packets using sockets.
• Decide who will write the client and who will write the server.
  • Whoever writes the client will write the transmission methods that send to the server and read for the client.
  • Whoever writes the server will write the transmission methods that send to the client and read for the server.
• Type in the stubs for all the methods.
• Start sending data between client and server, in both directions.
  • Begin by sending each other an asterisk; make sure it is received.
  • Next try sending a (4-byte) integer.
  • Try a two-byte integer.
  • Try a String, sending its length first and then the bytes of the String.
  • Now work on the FLAP frames.
    • Try sending a Data frame in each direction. Note the difference in format based on the direction: one way, the string in the Data frame is null-terminated; in the other direction, it is not.
    • Try senidng a Signon frame in each direction. Again, note the difference in format.
• Generate JavaDoc for your flap package.

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.