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 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 coordinate.
For example, you can now do out.writeChar('*') and in.readChar() instead of worrying about their representation as bytes.
If you have a short seqNum, then it can be written and read using out.writeShort(seqNum) and in.readShort().
As another example, you could send an x,y coordinate by:out.writeInt(x); out.writeInt(y)The above may be fields of a longer message whose type indicates a move of some sort on a board.
Consider Boggle and how a client specifies a word. An easy thing from the Client side is just to send the server the characters of a word, but then the server has to figure out if and where the word exists on the board. If instead the client sent the coordinates of the characters on the board, then the server need only determine if those coordinates follow the rules of Boggle words (e.g., no backtracking). This makes life slightly harder for the client but much easier for the server.
In either case the server has to verify that the resulting word is real, but the coordinates simplify finding where the word occurs on the board.
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.