SUP vs. INF SU

The post SUP vs. INF SU clarifies the use of features in the SUP vs INF SU. Basically, the SUP is for how messages are sent between two parties while the INF SU specify which messages may be sent. . I’d like to propose the inclusion of this distinction in the specification.

Features advertised in the SUP specify ‘how’ messages in the current connection may be sent. E.g., encryption or compression of the stream of data.

Features advertised in the INF SU field specify ‘what’ messages are (or may) be sent. E.g., user commands or bloom filters.

This should be added in the Features section so that it would completely be;

=== Features
Features are used to indicate support for protocol commands or functionality.

The server may use any feature that the client indicates support for regardless of its own SUP and vice versa. A client can announce features in the SUP regardless of the INF’s SU field and vice versa.

Features advertised in the SUP specify ‘how’ messages in the current connection may be sent. E.g., encryption or compression of the stream of data.

Features advertised in the INF SU field specify ‘what’ messages may be sent. E.g., user commands or bloom filters.

A feature name consists of four uppercase letters, where the last letter may be changed to a number to indicate a revised version of the feature.

A central register of known features is kept to avoid clashes, see below features in this protocol and the features in the extension document.

ADCS is signaled in INF SU instead of SUP


BLOM support is signaled in SUP


I’d say that INF SU should contain supports that matter for client-client functionality. Those exclude the ones that are only related to transferring files, except the supports that may be required to initiate the C-C connections (IP protocol, encryption, NATT).

This also reminds me of the mess with the supports:

  • Clients signal BLO0 while the specs has “BLOM”
  • Clients signal ADC0 while the spec shas “ADCS”
  • Clients signal SUDP in INF SU with SUD1 and/or SUDP
  • TYPE, FEED, DFAV and SUDP require the support to be signaled in INF and SUP (why both?)
  • The specs define that PFSR should be signaled in SUP but I’m not aware of any client doing this (the support isn’t signaled at all)
  • DC++ signals BZIP in C-C SUP but this isn’t mentioned in the specs
  • DC++ signals UCM0 in SUP that is sent to the hub but this isn’t mentioned in the specs

Telling clients to signal something in SUP is also rather inaccurate; SUP is sent in C-C connections but also when joining a hub (and the supports aren’t identical in both contexts).

I understand this view. I am simply trying to clear up the original intention of the difference. I’d have to ponder the implications of specifying what you’re saying - F-type could today be used for C-H messages, too, but that’d be impossible in that scheme.

By the way, TIGR (well, any hash reference) is an exception to PseudonypH’s and FarCry’s view: it should be signaled in the SUP but it isn’t about how communication is done (well, I can argue that 'hash algorithm to use in the communication of the connection" but I don’t think most people view the hash as such).

The current specification is slightly ambiguous about it, so I’m all for clarifying it, either way things go.

Ah, great. I was aware that there were problems with this, and I’m glad someone took the time to compile such a list.

There are two actions we can take (on each individual item); either change the spec or change implementations. The former is easy IFF all implementations use e.g. “BLO0” but more troublesome if some use “BLOM” as well. The obvious problem with modifying the implementations is that there needs to be an transition period where implementations all send the old form but accept the new (‘proper’) form, and then we remove the old form (i.e., phasing out ‘bad’ announcements). Modifying implementations means that they will properly match the spec, as it was agreed upon earlier - meaning a new implementation need only to follow the spec.

My guess is that many people will opt for the first suggestion (change the spec) and I have no problem with that: again, if and only if all implementations use the same. BLO0, SUD1/SUDP, UCM0 and ADC0 should be of these sorts. The following should probably be announced in SUP (if not already): SUD1/SUDP, ADC0/ADCS. The following should probably be announced in INF SU (if not already): BLOM/BLO0, UCM0/UCMD, FEED, DFAV, PFSR.

BZIP is an announcement that I feel we have a relatively low amount of versions implementing so I’d like to avoid changing the spec. (Especially since there is a distinction between the full vs get version of ZLIB.)

PFSR is something I feel should be announced in general, so it’d be my hope that implementations actually start signalling this. However, as per earlier, it should probably be signaled in INF SU. (F-type broadcast is nice in that regard.)

Yes, that would be much better.


What’s the reason for this? I assume that you mean the SUP that is sent to the hub?


Why is it relevant to have BLOM/BLO0 and UCM0/UCMD there? Those are C-H extensions and not relevant to be known by the other clients. I’d also like to consider the bandwidth usage here by not adding “junk” data in the INF.


I didn’t understand what you mean with this. Currently the specs don’t require announcing the BZIP support anywhere, but as I quickly checked the implementation in DC++, it really requires the support to be indicated. If the remote user doesn’t announce BZIP in the C-C SUP, DC++ will request the uncompressed XML list.


It might make sense so that clients wouldn’t blindly send partial search replies to all users regardless of whether they support the extension. But since it would break the compatibility with the current clients, I’m not sure if it’s a good thing to do in this point.

I think this approach isn’t the best one.

On the connection to the Hub the SUP field should contain all the extensions that may be relevant for the hub (this includes for example the ones used for feature broadcasts). Whilst the INF SU field should contain those that are relevant to other clients (since they modify the way in which a client will interact with another through the hub or via UDP).

Client to client SUP features should only include those relevant to the current connection.

BTW maksis, C-C BLOM support is a way to fix the issue with the up channel to the hub being blocked whilst the filter is sent.