Internet Pong Protocol

Tom Anderson suggested to a friend that they write (and play) a networked pong game (you know, the ancient ping-pong game). The obvious starting point is definition of a protocol for communication between the players; hence, the Internet Pong Protocol.

Game model

The game universe consists of a rectangular table, a ball and two paddles. The table has defined dimensions, the ball has defined position and velocity, and the paddles have defined positions. The table has four edges: two 'sides' and two 'ends'; the paddles are located at the ends.

When the ball strikes a side of the table, it bounces off. When the ball strikes a paddle, it bounces off. When the ball strikes an end, it falls off the table, and the player at the other end scores.

All coordinates are measured on an integer grid, whose origin is at the top left corner of the table; the X axis runs parallel to the sides, and the Y axis parallel to the ends. The player at the end with X = 0 is the left player, the player at the other end is the right player. Coordinate values never exceed 32767 (2^32 - 1).

Protocol context

This is a client-server protocol. A server manages the game, carries out the physics, etc, and a client interacts with the user. This protocol connects client and server; two such connections will be required per two-player game, one from the server to each player.

Connection state

When the connection is first opened, it is in the opening state. The client then logs in, and the connection moves to the open state. The client can then become involved in a game, in which case the connection moves to the ready state. When the game starts, the connection moves to the playing state. The connection can move from ready or playing back to open if the client or server aborts a game.

Elementary protocol format

IPP is a binary protocol. It consists of a stream of messages. Each message consists of a message-type byte, a length byte, and a series of data bytes, equal in number to the length byte.

All numbers transmitted are in unsigned or two's-complement signed format, in network byte order. All strings are in UTF8? (of which ASCII is a safe subset) and are not null-terminated (if necessary, a length byte is prepended).


In this section, messages are defined in list items, with the format "name <message-type number, in hex>: description; data format". In general, client messages have the high bit clear, and server messages have the high bit set.

Most messages may only be sent in a particular connection state; it is a protocol error to send a message in the wrong state.


Messages permitted in the opening state

Messages permitted in the open state

need to describe the game initiation process in the model section

need to say that the initiating player is the left player

need to tidy up states in request-response situations to rule out multiple sequential requests

Messages permitted in the ready state

Messages permitted in the playing state

Binding to transport protocol

At present, IPP is only bound to TCP, although it would be trivial to adapt this to other reliable ordered stream protocols, or to reliable ordered datagram protocols.


IPP may be used over TCP, in which case port 0x7067 (28775 in denary, "pg" as ASCII characters) should be used. Messages are simply packed into the data stream in order. Implementations should flush the stream after each message, or after the last message in a series.

Category Geekery

Tue, 17 Dec 2002 16:44:58 GMT Front Page Recent Changes Message Of The Day