The following is a suggested outline of the state in ADC. The text should simply be a rephrasing and restructuring of the state management in ADC and should not contain any modification to the actual state sequence. This does not take into account cologic’s proposed changes.
The connecting party is known as the client and the other is known as the server.
State is shared between the client and the server while the server (implicitly) controls state transitions.
The states, in login order, are PROTOCOL (feature support discovery), IDENTIFY (user identification, static checks), VERIFY (password check), NORMAL (normal operation), and DATA (for binary transfers).
A command is valid only in NORMAL unless noted otherwise.
The VERIFY state for C-C connections is not mandated by this specification and should be announced as an extension.
It is always the client that sends the first CTM/RCM command that is given control of the connection once the NORMAL state has been reached.
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 has sent the SID.
|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.
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.
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).
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.
Note that the hub’s INF is not required to be sent in IDENTIFY. The hub’s INF shall be sent in IDENTIFY or as its first command in NORMAL.
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.
The hub may initiate this state by sending its own INF in this state but is not required. The client shall send its INF whereby the hub shall verify the PD and ID fields and other required fields deemed necessary by the hub. The hub transitions the state then to VERIFY if the user is registered or NORMAL if not.
The server party in the client-client connection shall send its INF whereby the client party shall send its INF. The server transitions the state then to NORMAL (or VERIFY if an extension implements this).
The hub shall send a GPA whereby 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.
The hub shall send its INF if not done already. The server shall send the INF of all connected clients whereby 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 whereby the other party sends a SND followed with a stream of data.