SUP vs. INF SU

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list
Locked
Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

SUP vs. INF SU

Post by Pretorian » 24 Mar 2013, 14:27

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.

maksis
Junior Member
Posts: 23
Joined: 26 Nov 2010, 19:36
Contact:

Re: SUP vs. INF SU

Post by maksis » 24 Mar 2013, 15:52

Pretorian wrote: 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.
ADCS is signaled in INF SU instead of SUP

Pretorian wrote: Features advertised in the INF SU field specify 'what' messages are (or may) be sent. E.g., user commands or bloom filters.
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).

Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: SUP vs. INF SU

Post by Pretorian » 25 Mar 2013, 20:33

maksis wrote: 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).
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.
maksis wrote: 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).
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.)

maksis
Junior Member
Posts: 23
Joined: 26 Nov 2010, 19:36
Contact:

Re: SUP vs. INF SU

Post by maksis » 25 Mar 2013, 21:50

Pretorian wrote: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.
Yes, that would be much better.

Pretorian wrote:The following should probably be announced in SUP (if not already): SUD1/SUDP, ADC0/ADCS.
What's the reason for this? I assume that you mean the SUP that is sent to the hub?

Pretorian wrote:The following should probably be announced in INF SU (if not already): BLOM/BLO0, UCM0/UCMD, FEED, DFAV, PFSR.
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.

Pretorian wrote: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.
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.

Pretorian wrote: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.)
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.

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: SUP vs. INF SU

Post by klondike » 25 Mar 2013, 22:15

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.

Locked