- In “5.3.2. SUP”:
When the server receives this message in a client-client connection in the PROTOCOL state, it should reply in kind and > move to the IDENTIFY state. When the client receives this message in a client-client connection in the PROTOCOL state, it should send an INF about itself.
iceman50 has been testing this for weeks. Other DC++ and ncdc clients work unchanged. jucy would need fixing, but Quicksilver has agreed to do so. The failure mode is that C-C connections stop in the middle, but I’m not sure anything in the specification appears to require C-C clients to ever send an INF to begin with. (If I missed something, I’m quite curious where.)
This doesn’t address that 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.