ADC specification

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Locked
andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

ADC specification

Post by andyhhp » 18 Feb 2010, 20:50

Hello,

I am a hub developer and owner and have implemented ADC in a python-based, distributed hub.

However, I have a couple of queries about the specification (specifically as appears http://adc.sourceforge.net/ADC.html but this is the same as several other documents, including the adcportal wiki)

In section 5, you introduce the BASE messages with the contexts of F,T,C and U. First of all, whats the difference between the U and C of BASE as opposed to the U and C of BAS0? If there is no difference, why are they re-specified.

Also, what happens between F and T from BASE and H and I from BAS0? Are they supposed to superseed the BAS0 commands? (I have not come across a client which deals with "FSUP ADBASE ADTIGR" or "FSID <sid>" correctly even when the client sends ADBASE in its INF string, making F and T irrelevent). In addition to this, F (from hub) from BASE conflicts with F (feature broadcast). I know it is possble to distinguish them by looking forward in the string and working backwards, but this does cause ambiguity - "FSID ABCD" and "FSCH ABCD +TCP4 <blah>" are both valid messages as far as the protocol definition says, and worst of all, F is listed as valid contexts for both of them.

In section 6.1, you show an example Client-Hub handshake. For IINF, the parameters "HU1 HI1" appear but are never defined at all in the document. What do they mean and why dont they appear in the description of the INF parameters? (The reason that this problem comes up is that most clients seem fine to accept a IINF from a hub with the hub bit set in CT, but jUCy dies in agony if these parameters arnt present).


Is there a properly written, full specification of the ADC protocol anywhere? To even get our hub up and running, I had to reverse engineer the protocol from existing hubs, because the document seemed too ambiguous to follow correctly.

Unfortunatly, this results in a situation where each client and hub responds differently to what is intended to be the same commands.


I hate to sound as if I am complaining because I respect and activly encorage what you are doing, but having a complete specification to start with would make life so much easier for developers.

~Andrew

Toast

Re: ADC specification

Post by Toast » 20 Feb 2010, 14:16

I forwarded your question in DCDev so far no one has a clue

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADC specification

Post by Quicksilver » 21 Feb 2010, 02:54

1. I am not that much aware of BAS0 vs BASE spec.. thoughh is that important? BASE spec is waht counts and BAS= is only testspec for BASE. If there is no real difference it might just have been rewritten for beauty and understandability..

on "FSUP ADBASE ADTIGR" or "FSID <sid>" these just have no meaning. SUP message has currently only meaning from client to hub and back.. broadcast liek that is not done...

imho the intentions of the protocol defs was creating some sort of layer .. i.e. hub would only need to know about first letter of a command received by a client and then check target and source SIDs and act uppon them ... (potentially only INF would need further checking)
downside is that some commands can be created that have no meaning/are not useful .. upside is simplicity and openness for the future...

btw F broadcasts are feature broadcasts... so broadcasts between client and other clients. Where FSUP might be possible some day if some features requires it ... SID is marked being only in client-hub context so no feature broadcasts should be made with that.


--
In section 6.1,... probably that were just made up example flags ...there is no reason for not adding new flags.. so they probably just represent some example..
Though I would like to hear more about dying in agony.. without some more detailed error report in the jucy forum for example any misbehaviour found could be fixed in no time..

ADC spec afair is as it stands there ... though I am sure that any clarifications on the protocol are welcome... helpful further ressources are the wiki and the DCDev people in the DCDev hubs...

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

Re: ADC specification

Post by andyhhp » 21 Feb 2010, 05:20

@Quicksilver:
BASE spec is waht counts and BAS= is only testspec for BASE
I understand that but the specification makes no distinction between what is BAS0 and what is BASE. It says "if BASE is present, we add these new contexts"

Should that mean "these new four contexts override the previous ones" in which case H and I should no longer exist (this seems implied by the list of valid contexts with each command in section 5.3) or does it mean "these new four contexts should be used in conjunction with the previously defined ones" in which case H and I should mean the same as F(rom hub) and T. Most clients I have tried using seem to use H and I even when the hub specified ADBASE and specifically not ADBAS0, although this is mainly based on StrongDC and LinuxDC++.
on "FSUP ADBASE ADTIGR" or "FSID <sid>" these just have no meaning.
I beg to differ. The BASE protocol states in section 5 that the context F is used to mean "from hub" so as far as I can see, the hub is perfectly correct in replying with the F context rather than the I context.
In section 6.1,... probably that were just made up example flags
It would be nice if this were clarified - all the other flags shown in the example handshakes are genuine and required.
Though I would like to hear more about dying in agony
Here is the raw line capture from the point of view of the hub: (>: are incoming messages while <: are outgoing ones)

Code: Select all

>: HSUP ADBASE ADTIGR ADUCM0 ADBLO0
<: ISUP ADBASE ADTIGR
<: ISID VK54
<: IINF HU1 HI1 CT32 NIADtella@Cambridge DEADC/Dtella\snetwork\sat\sCambridge VEdtella-cambridge-1.2.4.5
>: BINF VK54 ID2POUVKZI47GUHHIQ5A56GTZ7JU4YRQQ5LUB6PBY PDQCSKXJQL3YTRSCTKOIJ7FVVQSA3Y773M4FTSW2Q NIandyhhp_jucy SL2 SS0 SF0 HN0 HR0 HO0 VEUC\sV:0.82 SUTCP4,UDP4,ADC0,KEY0 US12500000 U49086 KPSHA256/BEZWEILMD2EBTBCMEBFOY4K26QE2L3KKQG52F2IL3O EZUPNQN4QA I40.0.0.0
<: BINF MWYO ID3JX7VJINLK3JEZLOYD63EJK3L62IZEZGH5GM2RQ= I4127.0.0.1 SS0 SF0 VEDt:1.2.4.5/W US0 DS0 SL0 AS0 AM0 NI*Dtella
 DELocal\sDtella\sBot HN1 HR1 HO1 CT31
<: BINF VK54 NIandyhhp_jucy VEUC\sV:0.82;Dt:1.2.4.5/W SS0 U49086 I40.0.0.0 SUTCP4,UDP4,ADC0,KEY0 SF0 HR0 KPSHA256/BEZWEI
LMD2EBTBCMEBFOY4K26QE2L3KKQG52F2IL3OEZUPNQN4QA HN0 HO0 SL2 US12500000 ID2POUVKZI47GUHHIQ5A56GTZ7JU4YRQQ5LUB6PBY= CT0
<: ISTA 000 0.\sRequesting\sconfig\sfrom\scambridge.config.dtella.org...
>: HSTA 143 Need\sID\sin\sfirst\sINF FMID
This was taken from jUCy 0.82. The error would imply that one of the BINFs doesnt have an ID, but both clearly have. It seems I remembered the problem incorrectly - it was a while since I attempted to debug it. Is it possible that jUCy does not like the '=' padding at the end of the base64 encoded string and is flagging an error?

@Toast: :(

~Andrew

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADC specification

Post by Quicksilver » 21 Feb 2010, 12:34

yes jucy is stil not implementing full ADC spec/BASE
jucy needs ID in first inf even though it should not ...

and there are some other things still missing...

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: ADC specification

Post by Pietry » 23 Feb 2010, 18:12

1. BAS0 is pre ADC 1.0 BASE. The 0 means it's an early version of BASE.
2. You're saying the spec is weird but you're not reading it. Context is different of message type !

Contexts :
F From hub (hub-client TCP)
T To hub (hub-client TCP)
C Between clients (client-client TCP)
U Between clients (client-client UDP)

Message types:
B Broadcast Hub must send message to all connected clients, including the sender of the message.
C Client message Clients must use this message type when communicating directly over TCP.
D Direct message The hub must send the message to the target_sid user.
E Echo message The hub must send the message to the target_sid user and the my_sid user.
F Feature broadcast The hub must send message to all clients that support both all required (+) and no excluded (-) features named. The feature name is matched against the corresponding SU field in INF sent by each client.
H Hub message Clients must use this message type when a message is intended for the hub only.
I Info message Hubs must use this message type when sending a message to a client that didn't come from another client.
U UDP message Clients must use this message type when communicating directly over UDP.

on "FSUP ADBASE ADTIGR" or "FSID <sid>" these just have no meaning.


I beg to differ. The BASE protocol states in section 5 that the context F is used to mean "from hub" so as far as I can see, the hub is perfectly correct in replying with the F context rather than the I context.
F is the message type, not the context. in this case, the FSUP means a feature broadcast for the SUP message. According to the spec, the F message header is : f_message_header ::= 'F' command_name separator my_sid separator (('+'|'-') feature_name)+
and accordingly, your message must be similar to FSUP <sid> +TCP4 ADBASE

Hope this clears things up, if you have more questions don't hesitate to ask.
The only spec is the one you found, and it's quite clear to me.

The HI1 and HU1 are old flags used in earlier versions that were removed, but the example remained as it was. However, it's not wrong since unknown parameters must be parsed like any other parameter.

There is no need to reverse engineer, please ask what you need.
Just someone

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: ADC specification

Post by Quicksilver » 24 Feb 2010, 00:41

Due to the padding = on the ID the hash is not matched against the Regexp for Tiger192 -> the ID flag is dropped -> no ID is detected by jucy ..
and jucy does not fully implement ADC i.e. needs ID present -> without ID the user is invalid..

in general in DirectConnect the usual padding = are allways omitted!

Locked