Change the order between $MyINFO and $GetNickList
Moderator: Moderators
-
- Posts: 506
- Joined: 2003-01-03 07:33
Change the order between $MyINFO and $GetNickList
I think we should consider changing the order of two commands in the hub-client handshake.
Today it is;
$Version
$GetNickList
$MyINFO
Into;
$Version
$MyINFO
$GetNickList
This is more logical... one problem, some hubs might expect this order. I know that ptokax-hub might get confused. But i guess that can easily get fixed. (My solution is ofcourse nmdchub compatible).
Today it is;
$Version
$GetNickList
$MyINFO
Into;
$Version
$MyINFO
$GetNickList
This is more logical... one problem, some hubs might expect this order. I know that ptokax-hub might get confused. But i guess that can easily get fixed. (My solution is ofcourse nmdchub compatible).
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
I agree,
the GetNickList command is there for a reason. imho it's optional to get the NickList and OpList, so you shouldn't rely on it being sent ever.
"why let software break tomorrow, if we can break it today" ;)
the GetNickList command is there for a reason. imho it's optional to get the NickList and OpList, so you shouldn't rely on it being sent ever.
"why let software break tomorrow, if we can break it today" ;)
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
-
- Posts: 210
- Joined: 2003-01-23 17:24
- Location: Nevada
- Contact:
The way ivul suggested still makes more sense. Obviously, if you're going to make some checks on $MyInfo to validate it against hub-specific rules, you don't need to send the nicklist before the $MyInfo is validated. If you're going to kick the client right after, it's just a big waste of bandwidth.
Actually, SDCH never sends you the nicklist before you sent your $MyInfo (but it will gladly accept those 2 commands in any order).
Actually, SDCH never sends you the nicklist before you sent your $MyInfo (but it will gladly accept those 2 commands in any order).
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Posts: 506
- Joined: 2003-01-03 07:33
Wouldn't it be much easier to implement a delayed nicklist? (i.e. do not send nicklist until MyINFO has been recieved and only if it was requested)
It would maintain backwards compatibility at least.
It would maintain backwards compatibility at least.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- Posts: 506
- Joined: 2003-01-03 07:33
the fundamental point is that GetNickList should not be part of the hub-client handshake as it has nothing todo with the login-procedure or validation procedure (sharesize/slots/hubs). GetNickList is an optional argument that can be sent by a client who wants to know which users are online on the hub. By mixing in something that hasn't got anything todo with the handshake/validation the client sends more or less useless data to the hub during this state in the connection. When a user has been validated, then you say that you will answer with NickList, i.e. hubs should wait, and i agree.. ofcourse a well implemented hub doesn't do this before full validation (exampls; ASH, KDCH, dch++, etc...).
And i if you think from a hubDevelopers viewpoint, maybee nothing will change (probably not), i still feel its an error todo it like we have done today.
And i if you think from a hubDevelopers viewpoint, maybee nothing will change (probably not), i still feel its an error todo it like we have done today.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.