CSE 132 (Spring 2011)
Lab 5a: Protocol Design for Multiuser Game
- Grab a studio sticker for this lab,
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
- 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
We agreed in class on the following format for all messages.
Unless you can convince the professor otherwise, you are expected to
follow this outer-level description of all messages.
- 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
Your task is to design the messages that will be transmitted between the server and client for
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.
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.
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
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:
- 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.
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.
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
Last modified 12:37:32 CDT 14 April 2011
by Ron K. Cytron