CSE 132 (Spring 2011)
Lab 5a: Protocol Design for Multiuser Game

Notes

• Grab a studio sticker for this lab, and do your work in the studio10–yourstickername repository.

  • If you are doing Egyptian Rat Screw, then your tasks are:
    • Devise a way to keep clients from slap-cheating
    • Extend the game in some way
    • Try out the protocol in your group, and document the interactions that will occur.
  • If you are doing a different game, then you must start developing the protocol for your game, but you can use the class game protocol as an example.

• The file in which you specify the protocol is protocol.txt, which you can edit using eclipse.
• The Egyptian Rat Screw protocol can be found here.

Discuss the features you want (20 minutes)

• If you are doing ERS, then you must some features to what was done in class. Here are some suggestions, but you are invited to develop your own. Negotiate the set you must implement with the professor.
  • A time-out feature that causes a slow player ot lose a turn
  • A foyer for the game that allows people to choose between playing a game and observing one of the games in progress
  • A messaging facility so that players can talk with each other
• Try for interesting features for your game, but plan to cut back if the overall scope of the game is too ambitious.

  Spend some time discussing as a group the features you want in your game.

  Document your decisions in the protocol.txt file in your repo.

Message format at the outer level

• All messages start with a single byte whose value is the ASCII encoding of *
• The next byte specifies the type of the message as an unsigned value between 0 and 255, inclusively.
• The next two bytes specify the length of the payload (as with FLAP)
• The payload then follows. There is no specific character to terminate the payload, and the payload contents can be any sequence of bytes. The end of the payload is known because the length of the payload was previously specified.

Designing your message types

• The protocol you design must live between the server and the client, and both sides have to live with whatever decisions you make. You might proceed by trying for the simplest protocol for your side of the network, and then bargain with the other side to reach some kind of compromise.

  For example, consider how a played card is announced by the server.

• Avoid passing Strings between the client and server that require decoding on the other side. Instead, pass the information you need or want in the format that is best suited to the task.

  For example, don't pass a card as the string Jack of Spades. This would require parsing the contents of the string to find the rank and the suit. Instead, send two integers in succession for the card. The encoding for those integers must be very clear.

• Instead of dealing with low-level bytes at the socket level, you may want to use DataInputStream and DataOutputStream because they are already formulated to read and write all of Java's primitive types.

Your documentation must consist of the following sections in the following order:

• If you are doing ERS, start with the ERS messages and protocol and add what you need.
• If you are doing a different game, take a look at the ERS messages and protocol to get an idea about the documentation.

1. Message types and formats Explain the fields that are present for a given message type. Be specific about field names (to facilitate discussion), field lengths, valid values for a field, and the meaning/interpretation of each field.

   Recall the detail that was provided for FLAP in Studio 7. You must be specific about the number of bytes provisioned for each field of a message. You must also state the format of each portion of a message.

   Use common types where possible. For example, if the format for some field is a primitive Java type, such as short, then just say so, but indicate that 2 bytes are taken by the field.

   For each message type, document its specific fields in the same detail you should have specified for the overall message structure. Explain the circumstances under which you expect to see messages of a given type.

2. Dialog

   Describe the sequence of events and messages that should occur in the game. If a finite state machine helps to describe possible sequences of events, feel free to use such notation. Think of the states as points of arrival and the messages as triggers for action and state changes.

   Where possible, separate the portions of the protocol to simplify discussion. For example, there may be elements of the protocol that are unique to joining or leaving a game.

   Where possible, group similar protocol elements together in your document so that the similarity (or small differences) in their fields can be more easily appreciated.

Document the above in the protocol.txt file in your repo.

Finishing up

• Be sure the protocol.txt file is completed as required.

  If you are doing ERS be sure to complete the section documenting the extra features you plan to implement. Otherwise, the protocol won't make sense to the TAs.

• At the end of the file, type in the specification for your protocol. This does not have to be complete, and can be a work in progress, but it does have to be accurate.

When you done with this lab, you must be cleared by the TA to receive credit.

• Commit all your work to your repository
• Fill in the form below with the relevant information
• Have a TA check your work
• The TA should check your work and then fill in his or her name
• Click OK while the TA watches

If you worked in a team using a group– repository:

• Your work must be committed in that repository for this demo.
• Each team member must complete this form and have the TA authenticate.
  For example, if there are two of you, then the form must be submitted twice, so that each person's last name and 6 digit ID is captured with the repository name.
• The repository name must be included on each of the submissions.

---

group– ←Enter the name of your group repository here

---

	Last name	6-digit ID
1

---

TA: Password: