[ADC 1.0.2] ADC fix: IDENTIFY and NORMAL transitions in C-C

In order to fix some missing IDENTIFY and NORMAL state transitions in client <-> client connections:

  • Replace “5.1. Client – Hub communication” with

During login, the client goes through a number of stages. An action is valid only in the NORMAL stage unless otherwise noted. The stages, in login order, are PROTOCOL (feature support discovery), > IDENTIFY-WAIT, > IDENTIFY (user identification, static checks), VERIFY (password check), NORMAL (normal operation), and DATA (for binary transfers).

  • Replace the last two paragraphs of “5.3.2. SUP” with

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 > non-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.

When the server client receives this message in a client-client connection in the PROTOCOL state, it should reply in kind and move to the IDENTIFY-WAIT state.

the next state after SUP in a client-client connection is CLIENT-IDENTIFY, which transitions to SERVER-IDENTIFY, which finally transitions as now to NORMAL

  • Replace the states of “5.3.4. INF” with:

States: > IDENTIFY-WAIT> , IDENTIFY, NORMAL

[*]Replace the last paragraph of “5.3.4. INF” with:

When the server receives this message during client-client communication in > IDENTIFY-WAIT > state, it should verify the ID and TO fields, send an INF about itself and pass to the NORMAL state. > When the non-server receives this message during client-client communication in IDENTIFY, it should verify the ID and TO fields and pass to the NORMAL state.

[*]Replace the states of “5.3.12. QUI” with:

States: > IDENTIFY-WAIT, > IDENTIFY, VERIFY, NORMAL

All diffs bolded (and all bolded are diffs). I welcome verification that (1) the spec as it currently exists does not even recommend that a non-server in a C-C connection ever transitions to either IDENTIFY or NORMAL; and that my changes fix that. Pretorian made partial ADC state diagrams. Doing so a few years ago probably, unless I’m simply missing something, would probably have caught this.

These edits do not fix suboptimal phrasing or other issues with the spec, but target precisely the aspects that need to be changed for this purpose alone. They do not necessarily reflect intended final phrasing.

In particular, ADC needs to unambiguously distinguish between the ‘client’ and ‘server’ in a C-C connection; and between the ‘client’ and ‘hub’ in a C-H connection. There are ‘hubs’, ‘accept()ing clients’, and ‘connect()ing clients’; for C-H connections, the latter two are largely equivalent but for C-C connections they aren’t. Generally, the spec is good about distinguishing between a “hub” (for C-H connections) and a “server” for C-C connections, but I’m not sure there’s currently a better way to refer to the C-C partner than a “non-server client” or something similar. This probably should be improved more generally.

Similarly: is it a “a client-client connection” or “client-client communication”? The spec should be consistent. I’ve been locally consistent here (within each message), but generally I’d suggest switching to “a client-client connection”, since it’s both more precise and accurate.

iceman has been testing this for approximately a week across a large sample of other clients. Other DC++ and ncdc clients work unchanged. jucy would need fixing, but Quicksilver has already agreed to such a premise. The failure mode is that C-C connections stop in the middle - but, then, according to spec they can already do so (the non-server in a C-C connection has no obligation to enter either IDENTIFY or NORMAL right now).

I think you have misunderstood state transitions. They aren’t bound to one peer; they are shared between the 2 peers, and controlled by the server. This is detailed in section “5. BASE messages”, §2:

The connecting party will be known as client, the other as server. The server always controls state transitions.

See other topic about State management, closing since it’s old now.