I will be pushing the following to the SVN, if no one objects, on the coming Monday the 14th.
Three changes compared to the previous block-quote; removed the 'best-effort' sentence, removed the "NORMAL is default unless noted" and added the command/state matrix.
State management
ADC defines a state machine to control flow and processing of messages. The receiving end must ensure, according to the state machine, that it does not parse or drop messages while it is in the process of another state where the message might be invalid.
State description
|PROTOCOL |Feature support recovery
|IDENTIFY |User identification and static checks
|VERIFY |Password check (does not exist in C-C communication unless announced by an extension)
|NORMAL |Normal operation (end state)
|DATA |Binary transfers. The state changes back to NORMAL once the transfer is complete.
The states presented are the login order, from top to bottom.
States
PROTOCOL
When the hub receives a SUP, it should reply with its own SUP followed by SID assignment. The hub transitions the state then to IDENTIFY.
When the server party receives a SUP in the client-client connection, it should reply with its own SUP. The server transitions the state then to IDENTIFY.
IDENTIFY
The hub may initiate this state by sending its own INF in this state but is not required. The client should send its INF whereupon the hub shall verify the PD and ID fields and other required fields. The hub transitions the state then to VERIFY if the user is registered or NORMAL if not.
The client party in the client-client connection shall send its INF whereupon the server party shall send its INF. The server transitions the state then to NORMAL (or VERIFY if an extension implements this).
VERIFY
The hub shall send a GPA whereupon the client will respond with a PAS. The server transitions the state then to NORMAL.
Client-client support for VERIFY must be signaled as an extension.
NORMAL
The hub should send its INF if not done already. The server shall send the INF of all connected clients whereupon the connecting client's INF shall be last. Normal operation may then commence with chatting and file sharing.
Normal operation may commence immediately in a client-client connection. Typically, the downloading party sends a GET whereupon the other party sends a SND followed by a transition to the DATA state.
DATA
The DATA state is an actual binary transfer state, it does not have any commands or other content beyond streaming data.
The DATA state exist only in the client-client communication, an extension can be used to add binary transfers between a client and a hub. The DATA state commence after a SND command.
The state transitions back to NORMAL once the correct amount of bytes are transferred (specified by a previous command).
Notes
State always transitions from PROTOCOL to IDENTIFY and never from IDENTIFY to PROTOCOL. Likewise apply between IDENTIFY, VERIFY and NORMAL. This does not apply between NORMAL and DATA.
Successful commands sent after a state transition indicate that the next state has been reached. For example, PROTOCOL begins a connection and state changes to IDENTIFY once the hub sends the SID.
The state is shared between the client and the server while the server (implicitly) controls state transitions.
The connecting party is known as the client and the other is known as the server (or hub). The client initiates the connection and state machine by sending its own SUP.
A STA is valid in all states (except DATA) and may require that messages are resent (i.e. that the state transition does not occur).
It is always the client party in a client-client connection that sent the connection request (CTM/RCM) command that is given control of the connection once the NORMAL state has been reached.
Any party may disconnect the connection if they receive invalid data or insufficient data. All implementations must therefore be prepared for a potential disconnection following each command, meaning that the following state is not achieved. A disconnection should be preceded by a STA or a QUI to indicate what was wrong.
The hub's INF is optionally sent in IDENTIFY or in NORMAL.
BASE commands and state matrix:
State Commands
|PROTOCOL |STA, SUP, SID
|IDENTIFY |STA, INF, QUI
|VERIFY |STA, GPA, PAS, QUI
|NORMAL |STA, SUP, INF, MSG, SCH, RES, CTM, RCM, QUI, GET, GFI, SND
My idea is to replace the items 5.1 and 5.2 (Client-Hub/Client communication) with "5.1 State management".
In addition to the above new block, the following (explicit) content will be removed;
BASE Messages: The server always controls state transitions.
Client-hub communication and Client-client communication
INF: When the hub receives this message in PROTOCOL state, it should reply in kind, assign a SID to the client, optionally send an INF about itself, and move to the IDENTIFY state. When the server receives this message in a client-client connection in the PROTOCOL state, it should reply in kind, send an INF about itself, and move to the IDENTIFY state.
SID: The hub must send this command after SUP but before INF in the PROTOCOL state. The client, when it receives it, should send an INF about itself.
INF: When a hub receives this message in the IDENTIFY state, it should verify the PD and ID fields, and proceed to the VERIFY state by sending a PAS request or NORMAL state by sending its own INF (unless it already did so previously), then the INF of all connected clients in NORMAL state, and last the INF of the connecting client. When the server receives this during client-client communication in IDENTIFY state, it should verify the ID and TO fields, send an INF about itself and pass to the NORMAL state.
PAS: When validated, this transitions the server into NORMAL state.
SND: Transitions to DATA state [...] and then will transition back to NORMAL state
I will add a "State: X" to each message type so that it is explicit always.
In 6.2. (Client-Client connection), the example will be changed: the two INFs will switch order. (Client sends INF first.)
