SUGR - Support groups

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
FlipFlop™
Junior Member
Posts: 23
Joined: 17 Apr 2009, 08:29

SUGR - Support groups

Post by FlipFlop™ » 18 Nov 2010, 23:19

Idea: grouping of different supported features that are known to occur together frequently, can save bandwidth.

Hubbased implementation idea:

Client connects to hub, signals it supports SUGR, sends: HSUP <sid> ADSUGR AD..
Hub can send the groups to the client: SUGR <sid> GR<name>,<feature1>,<feature2> GR<name>,<feature1> etc..
for example: SUGR <sid> GRSECA,ADCS,KEYP,SUDP

From then on, when the hub receives all features in a certain group, it can send the groupname instead of all the separate features to all clients that support SUGR.

The client doesn't have to, or maybe even shouldn't use the groupnames when sending to the hub, only use them to parse incoming groups. It will only cost some bandwidth on the download side of the hub.

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: SUGR - Support groups

Post by darkKlor » 19 Nov 2010, 10:26

I'm not sure how much bandwidth this would save. Also the added complexity doesn't seem worth any small gain you may get.

The example seems to suggest adding 39 bytes (7 in the SUP and 32 from the SUGR message) to save 21 bytes. Am I reading this incorrectly?

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

Re: SUGR - Support groups

Post by Pretorian » 19 Nov 2010, 18:51

The point is not to save bandwidth in the SUP, but rather in the INF's SU field.

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

Re: SUGR - Support groups

Post by Pretorian » 21 Nov 2010, 17:24

There are a few things that should be noted/discussed;

When should the command be sent? Before hub INF?
The command length should be 3, not 4 characters...
If the SU field in the INF is used, then it's possible there will be a clash if someone picks a FCC that is the same as a group.. so, really a new field should be used.. 
Should groups in groups be possible? If yes, how do we identify groups from normal FCCs?

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: SUGR - Support groups

Post by andyhhp » 23 Nov 2010, 14:22

I agree with darkKlor.

Realistically, how many times is your client going to broadcast a change in its SU field?

My guess is never, after the login handshake.

From the hub point of view, you are making a tiny reduction per INF you have to send for the login handshake (and when new clients log in), but this is pittence compaired to the rest of the data sent in the INF

However, if you are concerned with the hub bandwidth, just get around to implementing ZLIF

~Andrew

Sulan
Junior Member
Posts: 16
Joined: 19 Jan 2009, 20:33

Re: SUGR - Support groups

Post by Sulan » 04 Dec 2010, 21:01

Agrees with darkKlor.

Locked