Errors on connect

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
goodtim
Posts: 16
Joined: 2006-02-13 16:06
Location: Worcester, MA
Contact:

Errors on connect

Post by goodtim » 2006-03-22 01:50

I have a question about the ADC protocol.

In my hub software, a set of basic checks are run on the intial client connection (before the ISUP is sent by the hub) to see if the hub should continue the protocol negotation. An example of one of these checks would be to see if the number of clients has exceeded the specified max clients.

In the case of one of these checks failing (e.g. there are too many clients connected) an error is sent back to the client in the form of an ISTA with a fatal severity code. However it appears that this error is not displayed in the chat window of DC++. I am not sure if this is a bug in DC++, or I am misunderstanding the protocol. Is this the correct behavior or should I run the checks once the protocol has been initailized?

I have included a sample output of my hubsoftware so you can better understand what I'm talking about.

Code: Select all

[3/22/2006 1:39 AM] [Notice] Listening for clients on 127.0.0.1:8000.
[3/22/2006 1:39 AM] [Notice] [127.0.0.1] Connected
[3/22/2006 1:39 AM] [Data] [127.0.0.1] Sent: ISTA 211 Sorry,\sbut\sthe\shub\sis\sfull.\sPlease\stry\sagain\slater.
[3/22/2006 1:39 AM] [Data] [127.0.0.1] Sent: IQUI INN7
[3/22/2006 1:39 AM] [Notice] [127.0.0.1] Disconnected

And on the DC++ side this is what is outputted.

Code: Select all

*** Connecting to adc://localhost:8000...
*** Connected
*** An existing connection was forcibly closed by the remote host.

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2006-03-22 05:19

Did you try delaying the disconnection by a couple of seconds?

DC++ also has an ADC debug mode, which you can enable by adding "<AdcDebug>1</AdcDebug>" to the settings xml. With that it should be possible to tell if dc++ processes the ISTA before the connection is closed.

goodtim
Posts: 16
Joined: 2006-02-13 16:06
Location: Worcester, MA
Contact:

Post by goodtim » 2006-03-22 15:55

I turned on AdcDebugging to see if DC++ was getting the command and this is the result:

Code: Select all

*** Connecting to adc://localhost:8000...
*** Connected
<ADC>ISTA 211 Sorry,\sbut\sthe\shub\sis\sfull.\sPlease\stry\sagain\slater. </ADC>
<ADC>IQUI EGV2 </ADC>
*** An existing connection was forcibly closed by the remote host.


So it looks like its getting the command, just not printing it out. I can try delaying the command, but either way, it seems DC++ should print the result of an fatal STA command. Especially since the the connection isnt closed until after a second command is recieved (the QUI) command.

goodtim
Posts: 16
Joined: 2006-02-13 16:06
Location: Worcester, MA
Contact:

Post by goodtim » 2006-03-22 15:58

Btw, Im also running the latest DC++ (0.688) hoping it was a bug in the version I was using (0.687) but I got the same result.

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

Post by ivulfusbar » 2006-03-23 02:55

Doing a short code-browsing we find:

Code: Select all

void AdcHub::handle(AdcCommand::STA, AdcCommand& c) throw() {
   if(c.getParameters().size() < 2)
      return;

   OnlineUser* u = findUser(c.getFrom());
   if(!u)
      return;

   // @todo Check for invalid protocol and unset SSL if necessary
   fire(ClientListener::Message(), this, *u, c.getParam(1));
}


So since no user exists, i guess the findUser(c.getFrom) probably returns NULL. I don't have a compiler right now in my pocket, but putting in a flag and running in debug-mode would tell you if this is whats going on.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

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

Post by ivulfusbar » 2006-03-23 03:15

After a short discussion with farcry we notice that STA makes no sence in the PROTOCOL-state where your message is sent. In the draft it says that STA can be sent in all states. Only SID and SUP makes sence in PROTOCOL-state.
This should be changed in my oppinion. I also noticed some messages lack the state-definiton, like MSG.. This has to be fixed for the new draft.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

goodtim
Posts: 16
Joined: 2006-02-13 16:06
Location: Worcester, MA
Contact:

Post by goodtim » 2006-03-23 15:54

This is what I assumed was going on, how then would you tell the user that an error as occured during the protocol negotation if no user has been defined. Simply disconnecting the client will undoubtly lead to a number of "OMG WTF?!?!?!!?!" posts, and I'm sure nobody wants that. :-)

goodtim
Posts: 16
Joined: 2006-02-13 16:06
Location: Worcester, MA
Contact:

Post by goodtim » 2006-03-23 15:57

Personally, I think the STA command should be able to be sent during the PROTOCOL state, but clients should print out a fatal error code, even if the user is not defined.

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

Post by ivulfusbar » 2006-03-23 17:01

What is the point of a hub sending a STA message to the hub without knowing if the client supports the same protocol as itself? What would it expect the connecting client todo with that message? The sain thing todo is instead to drop connections in this state.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2006-03-23 22:29

If the HSUP message is well-formed, but the hub cannot let the client join for some other reason (hub full...), sending a STA makes sense. However, sending it when there is a parse error doesn't.

Locked