Message headers

Discussion and questions about hub software
Locked
rhys_rhaven
Newbie
Posts: 9
Joined: 08 Oct 2008, 16:07

Message headers

Post by rhys_rhaven » 27 Jan 2009, 23:12

So I've been staring at the ADC spec, trying to figure out what goes to what.

Is there any correlation between a specific message header and a command?

Logically, MSG should be either Broadcast or Direct (for PM). But it never says that, and I don't know how different hubsofts will parse that. Trying to figure out how to parse them myself, which routing header goes to what? When is Echo ever used? These kind of things have me stumped. Does anyone who has dealt with this before have a solution.

Our university Hacker Society is trying to build a python based ADC client. This site gets all sorts of kudos for coming back. Ty Toast.

Rhys

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

Re: Message headers

Post by Pietry » 28 Jan 2009, 08:09

I think the topic is misplaced, it should have been in ADC questions not about the site itself.
Well, all the commands virtually have all the possible contexts. This mean that you can use MSG for example with B to send to everyone or with D to send to just one person. However, if you use D, the message goes to the target only. If you use E , the message will come back to you as well. This way you know that the message reached the hub safely and it came back to you ( avoids the funny thing that happened to NMDC when talking alone and the hub was dead ).
You could use F as well, why not a feature MSG broadcast? The protocol supports that.
You could use H to "talk to the hub" but it doesn't make too much meaning.
The idea is that the protocol is very flexible in this way allowing you to make a lot of constructs.
Another example
DSCH would mean to search just a single client, not all of them
BCTM would mean broadcast connect to me, which is quite weird, but possible if you want to get the file list from all the users.
Hope you get the meaning.
Regards
Just someone

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Message headers

Post by Dj_Offset » 28 Jan 2009, 14:37

The ADC spec is under specified in some aspects, especially these ones.

For instance, I never understood why one should send a INF message as a broadcast (BINF), instead of as a message directly to the hub (HINF). The hub will need to verify and possibly change the message before forwarding it anyway (which it could do with an "IINF").
Also, DINF, EINF and FINF *MUST* under all circumstances not be allowed.

So, it all boils down to just being a guideline for parsing and routing all the other message that the hub does not understand.

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

Re: Message headers

Post by Pietry » 28 Jan 2009, 16:32

before forwarding it anyway (which it could do with an "IINF")
Then, it won't have a SID ( which user the INF belongs to ? )
Also, DINF, EINF and FINF *MUST* under all circumstances not be allowed.
They don't seem too harmful, perhaps some future spec or extension may require this. The protocol is more flexible this way, even if for now they have no specific meaning
Just someone

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Message headers

Post by Dj_Offset » 28 Jan 2009, 17:08

Pietry wrote:
before forwarding it anyway (which it could do with an "IINF")
Then, it won't have a SID ( which user the INF belongs to ? )
The hub knows which user it got the HINF from, and will retransmit them in another manner to the client, what I am really suggesting is an asymmetric INF handling, which we already have in reality.
It will never happen, though - so, don't worry. ;)
Pietry wrote:
Also, DINF, EINF and FINF *MUST* under all circumstances not be allowed.
They don't seem too harmful, perhaps some future spec or extension may require this. The protocol is more flexible this way, even if for now they have no specific meaning
Read my post about "ADC security considerations for hubs".
I think I outlined the problems well there.

rhys_rhaven
Newbie
Posts: 9
Joined: 08 Oct 2008, 16:07

Re: Message headers

Post by rhys_rhaven » 29 Jan 2009, 17:05

So what needs to be done then, is to implement whatever function "PM, Message, Search All, Search User" in whatever way makes sense...connect to a test hub I set up and see if it works?

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Message headers

Post by Dj_Offset » 30 Jan 2009, 12:58

Handle these (at least):

recv:
SUP (I)
STA (D, E, I)
INF (B, I)
SCH (B, D, E, F)
MSG (B, D, E, F, I)
RES (D)
GPA (I)
SID (I)
QUI (I)
CTM (D)
RCM (D)

In addition, your client should be able to send:
SUP (H)
INF (B)
PAS (H)
MSG (B, F, D, E)
SCH (B, F, D, E)
RES (D)
CTM (D)
RCM (D)

The biggest job needed to be done is to ensure the INF message is parsed and used correctly.

Locked