DiningHackersProtocol » History » Revision 6
Revision 5 (Matthieu Herrb, 2018-08-01 12:21) → Revision 6/9 (Matthieu Herrb, 2018-08-01 12:22)
h1. 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"_
h2. 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.
h2. 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.
h2. 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:
h3. 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*
# SET NAME
Client sends 0x30 (up to 16 octets) 0x0a.
The command always succeeds.
# SET ST
Client sends 0x31 ST-octet
The command always succeeds.
# SET DX
Client sends 0x32 ST-octet
The command always succeeds.
# SET Aggr
Client sends 0x33 Aggr-octet
The command always succeeds.
h3. GROUP 2: GET PROPERTIES
*Operations*
# GET NAME
Client sends 0x3f 0x30 ("?0")
Server replies with 16 octets. The name is
a zero-terminated string.
The command always succeeds.
# GET ST
Client sends 0x3f 0x31 ("?1")
Server replies with the ST octet.
The command always succeeds.
# GET DX
Client sends 0x3f 0x32 ("?2")
Server replies with the DX octet.
The command always succeeds.
# GET Aggr
Client sends 0x3f 0x33 ("?3")
Server replies with the Aggr octet.
The command always succeeds.
# GET HT
Client sends 0x3f 0x34 ("?4")
Server replies with the HT octet.
The command always succeeds.
h3. GROUP 3: RESOURCE USAGE
# REQUEST LEFT CHOPSTICK
Client sends 0x4c ("L")
Server replies 0x30 on failure, 0x31 on success.
# REQUEST RIGHT CHOPSTICK
Client sends 0x52 ("R")
Server replies 0x30 on failure, 0x31 on success.
# DROP LEFT CHOPSTICK
Client sends 0x6c ("l")
The command always succeds.
# DROP RIGHT CHOPSTICK
Client sends 0x72 ("r")
The command always succeds.
h3. GROUP 4: OTHER
# SUICIDE
Client sends 0x51 ("Q")
The command always suceeds. The hacker and his chopstick are removed from the table.
Disconnecting has the same effect.
h2. INITIALIZATION
The character sheet is generated from random bits upon
connection. Until the client supplies data with SET
requests, he'll have a random 3-character name, HT 100,
ST in [5,15], DX in [5,15] and Aggr in [5,15].
h2. RESOURCE MANAGEMENT
The great difference from the Dining Philosophers
situation is that hackers have an attitude. They won't
starve while the neighbour is eating happily. They'll
attack their neighbours phisically with punches.
The ST, Aggr and DX stats shape the behavior. A
situation when a hacker may hit a neighbour is
called a hit roll, and is performed by the server.
Clients only find out they've been hit by checking the
HT with GET requests.
A hit roll is performed when a hacker already has
acquired a chopstick, tries to acquire the second
and fails. The hacker is anger at the neighbour who
caused the request to fail, and the server performs
a hit roll.
First the server rolls 3D6 (3 6-faced dice) against
the hacker's Aggr parameter. If the roll is greater
than Aggr, the hacker wasn't upset enough, and won't
proceed with the hit.
If the hacker proceeds with the hit, the server
rolls a dexterity dispute between the attacker
and the defender, with a +2 innitiative bonus for the
attacker. The roll is :
* Attacker: Attacker.DX + 1D6 + 2
* Defender: Defender.DX + 1D6
If the defender's result is greater or equal than the
attacker's result, he successfully dodged the punch, and
the hit roll is over.
Else, the punch hit, and the server will roll the
damage, which is
(Attacker.ST x 1D6) / 3
The damage is subtracted from the defender's HT.
A character is knocked out if his HT reaches 0 or
less. Knocked out characters are disconnected from
the server, and both the character and his associated
chopstick are removed from the table.
h2. STARVATION
The starvation timeout is ST x 3 seconds. The server
knocks off starved hackers.
h2. OBSERVATION SUB-PROTOCOL
The server also provides a secondary protocol for
processes willing to observe the global table
situation. The watcher makes a TCP connection
to port 8082. There's no greeting message, the
server starts listening for requests immediatelly.
To request a global overview the client sends
any octet to the server.
The server replies with a table snapshot made of
1 octet - H# : NUMBER OF ACTIVE HACKERS
and H# hacker state messages. Adjacent messages
represent adjacent hackers. Each message is 21
octets long:
16 octets - hacker name, zero-terminated
1 octet - ST
1 octet - HT
1 octet - DX
1 octet - Aggr
1 octet - eating flag, non-zero if the hacker
currently has two chopsticks in his
possession, zero otherwise.