THE DINING HACKERS PROTOCOL¶

April 14th 2001
Felipe Bergo <bergo@seul.org>

"You may have read April 1st RFCs, but no text ever came so close to a February-30th-RFC as this"

ABSTRACT¶

This document describes a protocol meant to provide a centralized service for clients ('dining hackers') who are fighting (more literally than in previous similar protocols) for a finite set of resources.

INTRODUCTION¶

The Dining Hacker protocol implements a situation similar to that shown in Dijkstra's Dining Philosophers paper.
A finite set of clients with different personalities are competing for a set of resources (chopsticks).

The situation is a round table with at N hackers, N <= 256.
There are always N chopsticks and N chinese food boxes on the table.
Hackers wish to eat, but one must first acquire the two chopsticks adjacent to his own position to start eating.
How much time and how frequently a hacker will eat depends on the client.
But conflict resolution is arbitrated by the server, using RPG-like character sheets.

The protocol itself is divided into 2 sub-protocols, each running on a TCP connection.

CLIENT SUB-PROTOCOL¶

The Client Sub-Protocol is used to connect a client (hacker) to the dinner table (server). The client connects to TCP 8081 of the server, which will send a greeting message and wait for requests.

The greeting message is terminated by a newline (0x0a) and the only requirement is that it contains the "DINNERD" string (in uppercase characters). Usually it will contain also a version number.

The following operations can be triggered by the client:

GROUP 1 : SET PROPERTIES¶

Each client has an associated "character sheet", with 5
properties: name (up to 16 octets), ST (Strength, 1 octet),
DX (Dexterity, 1 octet), Aggr (Aggressivity, 1 octet) and
HT (Health, 1 octet). All properties are read/write,
except HT which starts at 100 and is read only.

Operations¶

1. SET NAME
   Client sends 0x30 (up to 16 octets) 0x0a.
   The command always succeeds.
2. SET ST
   Client sends 0x31 ST-octet
   The command always succeeds.
3. SET DX
   Client sends 0x32 ST-octet
   The command always succeeds.
4. SET Aggr
   Client sends 0x33 Aggr-octet
   The command always succeeds.