DC++ and Double MyINFO

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

DC++ and Double MyINFO

Post by TasMan » 2003-04-24 16:01

When DC++ sends two myinfo. I know why (to update the hubs where the user is registered/op/etc).

A possible solution to this is to send MyINFO after the client recieves OpList. (After all the client sends "Version...GetNickList...MyINFO"). Since myinfo comes after GetNickList, it shouldn't cause a problem with logging in. OpList should be recieve before the hub processes a MyINFO string in the original protocol after all. (I assume OpList is what DC++ needs to check correct?)

Assuming that this works with PtoKaX, it probably would work with most hub softwares. It would make a lot of hub owners happy I think.

Or is there something I'm missing?
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-04-25 02:03

In many new hubsoftwares, MyINFO is an essential part of the handshaking between client and hub. You will not be allowed to grab the NickList before the handshake is done.

Sending a nicklist with 1500 users time 10 chars each to users that are not even welcome to the hub due to to low sharelimit or some other rule determined by the MyINFO-value.

Well we could get around this if $OpList is sent right after the client has Validated as an OP. i.e, before the $Hello reply from the hub.

But this last statment need some checking if its possible or not.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-04-25 03:41

Hmmmm so I'm guessing that the NickList request is queued and responsed to later? Hrumph. Though I had something there =)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

[ASH]Nev
Posts: 6
Joined: 2003-04-23 00:32

Post by [ASH]Nev » 2003-04-29 00:37

I almost fell out my chair until I read angelfusbars reply.

Even though GetNickList is sent before MyINFO I stall the NickList until the client have gone through all possible checks. Like ISP-IP check, ban-check and dc++ description scan and so fourth.

This ensures that ASH does not generate and send the NickList and OpList to clients that will not accepted in the hub. For large hubs, +1000 users, the combined data of NickList and N Hellos and N MyINFOs can reach 100k in size.

I rather have a few extra MyINFOs from registered users than sending NickList to any client that connects. I have found that the clients that are not welcome are the ones who hammer the most...

Waiting until MyINFO have been fullt checked before broadcasting the new user with an Hello and MyINFO to everybody also ensures a less freaky NickList in each client, as unwelcome clients won't blink in and out all the time.

As for protocol-compliance there is a mandatory request-response between ValidateNick and Version, but there isn't one between GetNickList and MyINFO. Hence dc++ is correct in not assuming that the hubserver will do fine with just GetNickList. As the protocol is reverse engineered, I think arne made the right move when he decided not to enforce any weird constraints on the protocol. When is GetPass valid? We don't know. When is LogedIn valid? We don't know. What should we do? Trust the hub.

If I can get a featureset to work in both nmdc and dc++, without making up new messages, it is protocol-compliant.

TasMan
Posts: 196
Joined: 2003-01-03 08:31
Location: Canada
Contact:

Post by TasMan » 2003-04-29 04:00

Indeed Nev.....after realizing my own folly, I went and implemented a delay nicklist =).

Give me a shout if you get that featureset going - I'd probably support it.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....

[ASH]Nev
Posts: 6
Joined: 2003-04-23 00:32

Post by [ASH]Nev » 2003-04-29 12:32

There is no solution to the double MyINFO thingy as there is no problem with it.

dc++ connects to one or more hubs and after some initial handshaking eventually send a correct MyINFO to the hub. If it receives a $LogedIn from any hub it is connnected to it recalculates the H: for the description and send this new correct MyINFO to all hubs it is connected to.

What looks like a double MyINFO to one hub may be important news to another......

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-04-29 14:33

If it receives a $LogedIn...
actually, I was just near that code today. DC++ does fire an event on $LogedIn, but no one is listening. instead, the OPness of the user is recognised through the $OpList

(in previous versions DCH++ never sent $LogedIn, and first after a while the complaint came that NMDC OPs didn't get their Kick/Redirect menu items. a bit reluctantly *g* arne went ahead and added $LogedIn)
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)

Nev
Programmer
Posts: 40
Joined: 2003-01-03 13:29

Post by Nev » 2003-05-01 07:19

Isn't LogedIn used to control the H: thingy? Or does dc++ simply decrement H: when a MyPass is sent to a hub?

Wouldn't it be nice, and more correct, if the LogedIn controlled the H: thingy? Then we could have hubs with so called VIP accounts in which the hub do send LogedIn and H: is decremented. But we could also have registered users, ie nick and pass only to protect and authenticate the nick, without sending LogedIn and the user would not have the benefit from having H: decremented.
[url=dchub://ancient.myftp.org]ancient.myftp.org - [BBB][Sunet][Tele2] ONLY! @ 20GB (ISP/IP/Share Scripted)[/url]

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-06-02 22:36

Well, DC++ sends multiple MyINFO in other situation aswell which has nothing todo with the H-tag. Try to add a directory or remove a directory in your share and you will se. This is probably due to the fact that clicking OK in setting aswell as ShareManager::run will do an update. Well, diff -u will come as soon as i get some spare time, probably tomorrow.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

Locked