CSE 132 (Spring 2010)
Lab 5a: Protocol Design for Multiuser Game
- Grab a studio sheet for this lab.
Do your work in a studio10–yourgroupname repository.
The file in which you specify the protocol
is protocol.txt, which you can edit using
- Class notes on Kassle, The Game and its protocol can be found here.
Discuss the features you want (20 minutes)
- If you are doing Kassle, The Game, 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 Kassle and how a successful move is announced by the server.
The server could just send the current state of the board. If the move rotated a row, then
the client has to determine which row was rotated, but the server knew that before
sending the board. A better protocol from the client's
point of view would announce the move instead of sending the board.
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 coordinate as the string (1,2). This would require parsing the contents of the
string to find the 1 and the 2. Instead, send two integers in succession for the
- 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.
you could send an x,y coordinate by:
The above may be fields of a longer message whose type indicates a move of some sort on a board.
Your documentation must
consist of the following sections in the following order:
Take a look
at what we did for the kassle messages and protocol
to get an idea
- 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 Kassle, The Game
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.
Last modified 08:59:25 CDT 03 June 2010
by Ron K. Cytron