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
Message headers
-
- Senior Member
- Posts: 328
- Joined: 04 Dec 2007, 07:25
- Location: Bucharest
- Contact:
Re: Message headers
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
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
-
- Member
- Posts: 53
- Joined: 15 Sep 2008, 21:48
- Location: adcs://adcs.uhub.org:1511
- Contact:
Re: Message headers
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.
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.
-
- Senior Member
- Posts: 328
- Joined: 04 Dec 2007, 07:25
- Location: Bucharest
- Contact:
Re: Message headers
Then, it won't have a SID ( which user the INF belongs to ? )before forwarding it anyway (which it could do with an "IINF")
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 meaningAlso, DINF, EINF and FINF *MUST* under all circumstances not be allowed.
Just someone
-
- Member
- Posts: 53
- Joined: 15 Sep 2008, 21:48
- Location: adcs://adcs.uhub.org:1511
- Contact:
Re: Message headers
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.Pietry wrote:Then, it won't have a SID ( which user the INF belongs to ? )before forwarding it anyway (which it could do with an "IINF")
It will never happen, though - so, don't worry.
Read my post about "ADC security considerations for hubs".Pietry wrote: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 meaningAlso, DINF, EINF and FINF *MUST* under all circumstances not be allowed.
I think I outlined the problems well there.
-
- Newbie
- Posts: 9
- Joined: 08 Oct 2008, 16:07
Re: Message headers
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?
-
- Member
- Posts: 53
- Joined: 15 Sep 2008, 21:48
- Location: adcs://adcs.uhub.org:1511
- Contact:
Re: Message headers
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.
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.