Change the order between $MyINFO and $GetNickList

ivulfusbar · Post by **ivulfusbar** » 2003-06-13 05:14

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).

Sedulus · Post by **Sedulus** » 2003-06-13 05:54

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" ;)

ender · Post by **ender** » 2003-06-13 06:50

This will break in existing PtokaX hubs. DCGui used to send the commands in this order, and wasn't able to connect to any PtokaX, as it requires $GetNickList before $MyINFO (it's the same with some other hubs)...

ButterflySoul · Post by **ButterflySoul** » 2003-06-13 08:51

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).

Post by **GargoyleMT** » 2003-06-13 15:22

Would this be one of those changes "that would be nice to know about" for hub software authors, perhaps, similar to the H: change? I assume aMutex and the Ptokax author, etc. check here? If not, does anyone want to broach the subject of a possible change before it happens?

ivulfusbar · Post by **ivulfusbar** » 2003-06-13 15:36

i will discuss it with ptazcek next time i see him...

lets-spread-the-word-ly'ers ,))

TasMan · Post by **TasMan** » 2003-06-13 16:40

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.

ptaczek · Post by **ptaczek** » 2003-06-14 13:40

I agree. In 0.326 TestDrive 4 it will be acceptable even in prokax ;)

xayide · Post by **xayide** » 2003-06-14 15:13

I agree fully......Reall good for getting bandwidth/CPU load down on Hubs as big hubs tend to have alot fo unwanted visitors.....

ivulfusbar · Post by **ivulfusbar** » 2003-06-14 15:44

well, as everyone seems to agree with me, i don't think that this will be to hard... atleast not when a stable new ptokax-version has been running a couple of weeks...

Post by **arnetheduck** » 2003-06-16 09:56

I don't. Why bother? In dch++ it takes a boolean and three lines of code to delay the sending of the nicklist until myinfo's received, and considering peoples unwillingness to upgrade/change client, the hubs should deal with it anyway.

ivulfusbar · Post by **ivulfusbar** » 2003-06-16 10:08

why? because it is more logical, there is no reason at all todo as you have done it in the curent implementation.

ivulfusbar · Post by **ivulfusbar** » 2003-06-16 10:38

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.