ADC Handshake

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
Flow84
Posts: 31
Joined: 2004-11-08 17:59

ADC Handshake

Post by Flow84 » 2006-04-27 15:56

Hi.

Im wondering why there has been a change on who is sending first message in ADC protocol compared to NMDC.
NMDC wrote: Hub
$Lock <lock> Pk=<pk>|
Client
$Key <key>|$ValidateNick <nick>|
Hub
$HubName <name>|$Hello <nick>|
Client
$Version <version>|$MyINFO <info>|$GetNickList|
ADC wrote: Client
HSUP +BASE <other>
Hub
ISUP +BASE <other>
ISID <client>
IINF HU1 HI1 …
Client
BINF <my> ID... PD…
Hub
IGPA …
Client
HPAS …
Hub
BINF <all>
BINF <Client> …
If the hub was sending first message in ADC too, there would be easy to make a NMDC/ADC Client hybrid as you would only need to react different depending on what command you get.

And the user wouldnt need to be bother at all.
This would make it invisable for the user that a hub converted from a NMDC hub to a ADC hub.

Now i have stated my question and why.
So please let me hear the reason why you have changed =)

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2006-04-27 20:17

Because every good RFC protocol has the client speak first. Having the server speak first is kind of dumb.

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2006-04-28 01:31

Could the client simply open a port, wait a little while for a response, and if it doesn't get a $Lock simply send the HSUP? A bit dirty sure, but it would work in most cases.

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2006-04-28 02:28

Todi wrote:Could the client simply open a port, wait a little while for a response, and if it doesn't get a $Lock simply send the HSUP? A bit dirty sure, but it would work in most cases.
We actually tried this with success, but I'm afraid that some hubsofts would disconnect if infact using NMDC but is a bit slow, because it would think it was junk data...
<random funny comment>

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2006-04-28 07:17

PseudonympH wrote:Because every good RFC protocol has the client speak first. Having the server speak first is kind of dumb.
Isn't SMTP a counterpoint to this?



However, even if they were the same order, DC++ wouldn't be able to switch them without a changes. It decides based on the format of the hub name whether to treat it as an ADC hub or a DC hub one. I also think that making it somewhat manual for the client is important -- you can easily send a redirect on DC to get users to go to an ADC hub.

youshi10
Posts: 2
Joined: 2006-06-16 17:57

Post by youshi10 » 2006-06-17 10:30

PseudonympH wrote:Because every good RFC protocol has the client speak first. Having the server speak first is kind of dumb.
Not only that; having the server speak first kind of defies the whole role or client and server, in the sense that client seeks to create active connections, where servers service clients requests by facilitating those requests as best necessary.

NickDanger
Posts: 1
Joined: 2006-08-19 01:28
Location: Nick Danger Headquarters, Missouri
Contact:

Post by NickDanger » 2006-08-19 02:41

PseudonympH wrote:Because every good RFC protocol has the client speak first. Having the server speak first is kind of dumb.
Fair enough, but what if the client is really shy, but really has feelings for the server and just has issues expressing the way that it feels?

Is it okay for the server to speak first under these circumstances?

:lol:
-Nick Danger
Image

Dolda2000
Posts: 20
Joined: 2003-11-12 20:11
Location: Täby, Sweden
Contact:

Post by Dolda2000 » 2006-08-22 18:12

youshi10 wrote:
PseudonympH wrote:Because every good RFC protocol has the client speak first. Having the server speak first is kind of dumb.
Not only that; having the server speak first kind of defies the whole role or client and server, in the sense that client seeks to create active connections, where servers service clients requests by facilitating those requests as best necessary.
I'm not quite sure I can agree with that. Not only are SMTP, IMAP, POP3, FTP, SSH et al. counterexamples to the original point, but also consider that the connection attempt itself very well could be considered a request to the server, which should be dignified with a response. In particular, that allows the server to respond to the client immediately with a confirmation or rejection of the connection attempt, and allows to specify a more targeted error message upon rejection than just a TCP RST (like the SMTP 4xx error for telling the other side that the server is overloaded for the moment).

Not that I'm saying that your points are bad -- I'm just saying that they aren't universal. Rather, I'd say it depends very much on the protocol in question. I'm not sure which one would be most suitable for the ADC protocol, but please don't just dismiss the issue by saying that "the server goes first" is bad programming in general. The OP's point isn't entirely bad either, though I think it would be rather unreliable to just rely on the server talking first to determine which protocol to speak. In particular, it would feel a bit stupid to change the protocol so fundamentally at this time for such a small advantage.

fluke
Posts: 3
Joined: 2006-12-06 13:25

Post by fluke » 2006-12-06 15:45

From how I read the ADC protocol, it sounds like the hub has the option to speak first. There is nothing in the description that prohibits the hub from sending a SUP or STA immediately on connect. It is clear from the description that after the client sends it's SUP that the hub should respond with it's own SUP (even if it already provided it before). For a ADC protocol banner similar to SMTP, FTP and so on, I would recommend issuing a "ISTA 010" followed by the greeting string. But a client must still assume that an ADC hub will reserve responding until it gets a HSUP from the client.

Btw, ADC protocol draft 0.12 contains a badly worded line of:
"When the server receives this message the first time, it should reply in kind, assign an SID to the client, send an INF about itself and move to the IDENTIFY state."

It should say:
When the server receives this message the first time, it should reply in kind, assign an SID to the client, move to the IDENTIFY state and send an INF about itself.

As it is worded now, it sounds like the client should be able to always expect an IINF after an ISID (and that INF is being sent as part of the PROTOCOL state). As part of being moved into the identify state, it becomes valid for the hub to send a IQUI right after the ISID instead of a IINF.

The issue that bothers me the most about the handshake in ADC protocol draft 0.12 is that there is always the overhead of assigning a sid before being able to send a URL redirect. It would be nice if the protocol description allowed for use of the QUI flag of RD when using the STA command. For example, when the hub is full I would like to be able to immediately send to any further connection attempts the following:

ISTA 211 Hub is full, redirecting to less busy sister hub RD=adc://sisterhub

I can think of cases where use of the RD flag would be nice for any STA codes of 21x (generic hub error), 22x (login/access error) or 23x (kick/ban/disconnects).

In terms of auto-detection of hub type, it should not matter if ADC provides a banner or requires the client to send first. Instead, the ADC protocol should make it a requirement that the hub never silently close/time-out a connection. Rather, issuing a STA or QUI should be mandatory. Hence, if a client waiting for a $Lock gets time-out with an STA, it should automatically mark the profile as being an ADC client and reconnect. It should be fairly rare that someone would downgrade an ADC hub back to a DC hub. So, once autodetection of an ADC hub via time-out is discovered then no further autodetection should be needed.

Locked