SUP vs. INF SU

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
Dolda2000
Posts: 20
Joined: 2003-11-12 20:11
Location: Täby, Sweden
Contact:

SUP vs. INF SU

Post by Dolda2000 » 2006-08-13 11:01

I just read through the ADC spec. (v0.11), and I don't understand the difference between the data sent in the SUP command and the SU parameter to the INF command. Both seem to indicate FOURCCs of supported features, so what is the difference between the two?

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

Post by GargoyleMT » 2006-08-14 18:54

One is seen by the hub/client, and one is intended to be broadcast to other clients through the hub? (In common usage.)

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

Post by PseudonympH » 2006-08-14 23:51

The SUP command is connection-local, so it only pertains to how messages are sent. This includes features like ZLIF/ZLIG and encryption. The SU field is for which messages are sent, and is therefore what F-type messages use. In this way, message dispatching logic can be separated from the logic to stream messages in a hub implementation.

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

Post by Dolda2000 » 2006-08-16 08:54

Thanks, I think I kind of get it. SUP is for the communication between the hub and the client (like whether the client supports compression/encryption, or whether it matters if the client receives regex searches), while INF SU is for capabilities that others in the hub may care about (like whether it's possible to connect to someone actively). That's about right, isn't it?

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2006-08-16 17:48

Not quite, read again what PseudonympH wrote. SUP holds information that directly pertains to the connection it is sent on (not only client-to-hub, but also client-to-client). It only specifies what features both parties can use for communication on that connection. That includes the set of commands both understand (BASE protocol) and if the data may be encrypted or compressed. The SU field contains all features of a client that might be of interest to the hub or other clients in any way. The F-type message is one example how both hub and clients may use that information.

Locked