DiningHackersProtocol » History » Version 1
Matthieu Herrb, 2018-08-01 12:10
| 1 | 1 | Matthieu Herrb | h1. THE DINING HACKERS PROTOCOL |
|---|---|---|---|
| 2 | |||
| 3 | April 14th 2001 |
||
| 4 | Felipe Bergo @<bergo@seul.org>@ |
||
| 5 | |||
| 6 | _"You may have read April 1st RFCs, but no text ever came so close to a February-30th-RFC as this"_ |
||
| 7 | |||
| 8 | |||
| 9 | h2. ABSTRACT |
||
| 10 | |||
| 11 | 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. |
||
| 12 | |||
| 13 | h2. INTRODUCTION |
||
| 14 | |||
| 15 | The Dining Hacker protocol implements a situation similar to that shown in Dijkstra's Dining Philosophers paper. |
||
| 16 | A finite set of clients with different personalities are competing for a set of resources (chopsticks). |
||
| 17 | |||
| 18 | The situation is a round table with at N hackers, N <= 256. |
||
| 19 | There are always N chopsticks and N chinese food boxes on the table. |
||
| 20 | Hackers wish to eat, but one must first acquire the two chopsticks adjacent to his own position to start eating. |
||
| 21 | How much time and how frequently a hacker will eat depends on the client. |
||
| 22 | But conflict resolution is arbitrated by the server, using RPG-like character sheets. |
||
| 23 | |||
| 24 | The protocol itself is divided into 2 sub-protocols, each running on a TCP connection. |
||
| 25 | |||
| 26 | h2. CLIENT SUB-PROTOCOL |
||
| 27 | |||
| 28 | 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. |
||
| 29 | |||
| 30 | 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. |
||
| 31 | |||
| 32 | The following operations can be triggered by the client: |
||
| 33 | |||
| 34 | h3. GROUP 1 : SET PROPERTIES |
||
| 35 | |||
| 36 | Each client has an associated "character sheet", with 5 |
||
| 37 | properties: name (up to 16 octets), ST (Strength, 1 octet), |
||
| 38 | DX (Dexterity, 1 octet), Aggr (Aggressivity, 1 octet) and |
||
| 39 | HT (Health, 1 octet). All properties are read/write, |
||
| 40 | except HT which starts at 100 and is read only. |
||
| 41 | |||
| 42 | h4. Operations |
||
| 43 | |||
| 44 | # SET NAME |
||
| 45 | Client sends 0x30 (up to 16 octets) 0x0a. |
||
| 46 | The command always succeeds. |
||
| 47 | # SET ST |
||
| 48 | Client sends 0x31 ST-octet |
||
| 49 | The command always succeeds. |
||
| 50 | # SET DX |
||
| 51 | Client sends 0x32 ST-octet |
||
| 52 | The command always succeeds. |
||
| 53 | # SET Aggr |
||
| 54 | Client sends 0x33 Aggr-octet |
||
| 55 | The command always succeeds. |