"Hidden" reconnecting - bother.

gourmet · Post by **gourmet** » 2003-09-19 22:08

Now DC++ reconnects to users after line is available again (after dropped). DC++ doesnt' connect to HUB. Only to users. DC++ doesnt show on-line hub users and cannot search in there.

Feature request - clearly reconnect to hub if line is up again.

Twink · Post by **Twink** » 2003-09-20 06:37

i thought it reconnected automatically unless there was a nick in use error

Gasman1015 · Post by **Gasman1015** » 2003-09-20 08:21

It does if the hub is checked and in you fav's.

TheParanoidOne · Post by **TheParanoidOne** » 2003-09-20 08:31

Twink wrote:i thought it reconnected automatically unless there was a nick in use error

Indeed.

Gasman1015 wrote:It does if the hub is checked and in you fav's.

You're probably thinking about system startup. As far as I can see, gourmet is talking about disconnection and reconnections while using the program.

gourmet · Post by **gourmet** » 2003-09-20 08:55

thought it reconnected automatically unless there was a nick in use error

Of course I told about this. If nick is free - reconnection goes well. But if "nick was already taken" - then after time DC++ doesnt' reconnect to server but restarts downloading from users as well.

gourmet · Post by **gourmet** » 2003-09-20 09:10

Sorry I'd like explain a little bit more.

Time interval for reconnection attempt in DC++ cannot be changed in settings. And it is less than I-know-this-nick-time on server. If the line dropped - then DC++ tries reconnect after delay but recieves "your nick was already taken" state. Then DC++ tries reconnect again after time - attintion from here - and reconnects only to users, but not to the hub. The hub already forget my nick and is open form again. But I dont' see users in hub list and I dont' see hub messages. But I see all dowonloads started. If I strike "reconnect" button - then I get normal connection.

Gasman1015 · Post by **Gasman1015** » 2003-09-20 10:05

TheParanoidOne wrote:
Twink wrote:i thought it reconnected automatically unless there was a nick in use error
Indeed.

Gasman1015 wrote:It does if the hub is checked and in you fav's.
You're probably thinking about system startup. As far as I can see, gourmet is talking about disconnection and reconnections while using the program.

No, I was'nt refering to system start up, very often hubs reset but always reconnect in my setup, I do have a tendency to make the hubs from which I am currently downloading favourites and they always reconnect.

gourmet · Post by **gourmet** » 2003-09-20 10:38

This depends from nick lifetime on server. If this time is greater than timout in client - then problem appeares.

Gasman1015 · Post by **Gasman1015** » 2003-09-20 12:07

gourmet wrote:This depends from nick lifetime on server. If this time is greater than timout in client - then problem appeares.

As far as I can make out the client attempts to reconnect every 60 seconds, if their is a problem with the nick then that is from the server side not the client.

gourmet · Post by **gourmet** » 2003-09-20 12:35

The problem in client is - on successful attemp to reconnect after taken nick state clent actually doesnt' connect to server but only to other clients.

Gasman1015 · Post by **Gasman1015** » 2003-09-20 12:59

You still seem unable to grasp what I am trying to say.

You want a feature in DC++ to be able to set the timeout of reconnecting after being disconnected by the hub. Is that correct.

You say that if there is a problem with your nick then DC++ does not reconnect to the hub. Is this also correct.

But what I am saying is that DC++ attempts to reconnect to the hub every
60 seconds and will continue attempting, if there is a problem with your nick, then DC++ will still attempt to reconnect every 60 seconds.

Now there are some hubs out there at the moment experiencing nick problems, PtokaX hub software for one and no amount of alteration by the client will enable it to connect.

Therefore what I am trying to point out is that the problem you are experiencing is caused by other software and not DC++ and the feature you suggest will be of no use.

If I am wrong about this you can be sure someone will be quick to correct me.

gourmet · Post by **gourmet** » 2003-09-20 15:16

You want a feature in DC++ to be able to set the timeout of reconnecting after being disconnected by the hub. Is that correct.

If that was a question then my answer: NO. I want DC++ clearly auto reconnect after "your nick was already taken" state.

You say that if there is a problem with your nick then DC++ does not reconnect to the hub. Is this also correct.

Almost yes. If the nick was "taken" (because of server timeout) - then DC++ doesnt' reconnect to hub. "Nick taken" state is not a problem with nick indeed.

[/i]Therefore what I am trying to point out is that the problem you are experiencing is caused by other software and not DC++ [/i]

No this is a problem with DC++ - it reconnects well manually, but not auto. If there was a problem with other software - then DC++ would have same problem in manual reconnection.

Twink · Post by **Twink** » 2003-09-20 17:55

I think the least dc++ could do is make the hub tab go red on nick in use, as ur not really connected are you (I posted a bug tracker thing about this a while ago). I seem to remember reading the reason dc++ didn't try reconnect when it got the "nick in use" error is that there might actually be a user called that on the hub.

Twink · Post by **Twink** » 2003-09-20 18:27

well after playing around in the dc++ code for a little while I found that this wasn't exactly hard to do.

case ClientListener::VALIDATE_DENIED:
- client->removeListener(this);
- client->disconnect();
speak(ADD_STATUS_LINE, STRING(NICK_TAKEN));
+ speak(DISCONNECTED);
break;

the plus was the only line added, and the minus were lines removed. I'm not sure what kinda affect this will have, however it makes the download tab red on nick in use, and appears to try to reconnect, I'm just worried about side effects. This doesn't do anything for the problem of dc++ still trying to connect to users when nick in use comes up.

Twink · Post by **Twink** » 2003-09-20 18:30

oh btw this was done in hubframe.cpp around line 1500

gourmet · Post by **gourmet** » 2003-09-22 04:16

There could be good behavior of DC++ while nick used - just attempt to connect untill nick become free (there could be better behavior - reserving nick, but not supoorted on server side). If the nick is free - then connect to server. Unfortunately now it doesn't connect to server but to clients only.

And there could be very good solution for the line dropped case. SERVER must use cookies to save info about session with particular user. Cookie must have expiration time same as nick lifetime on server (this all doesnt' relate to Web-browser, I just use same terms). If the line dropped on client side and client has alive cookie with pair Nick:SessionID - then server must open session for this client.

Of course this all affect server and client code.

cyberal · Post by **cyberal** » 2003-09-22 05:07

I think this problem should be solved in the hub software, I know there are many scripts to do it! Gourmet, I suggest you talk to the hub owner about this..

doesn't DC++ react to the "nick taken" string? If the hub would simply send another message, would the client still think his nick was taken?

gourmet · Post by **gourmet** » 2003-09-22 06:24

Guys... You all like didnt' read my mesasages. If I strike "reconnect" button manually - it connects well. That means my nick is already FREE. But if it tries connect auto - it connects only to clients. DC++ didnt' receive error message. It stops attempts to connect to hub. This all in chat window looks like:

<message>Connecting to....
<message>Connected.
<message>Your nick was already taken. Change to something else.
...1 minute delay...
<message>Connecting to....
<message>Connected.
<message>Your nick was already taken. Change to something else.
...1 minute delay...
<message>Connecting to....
no more messages in chat, no users list appeared, no hub invitation message, but I see downloads from other clients started

There were 3 attempts connect to hub and twice nick was occupied. On 3d attempt nick was already free but I didnt' get connected. If I strike Reconnect button - even before or after 3d auto attempt - I will get connected as well.

Lightning Man · Post by **Lightning Man** » 2003-09-22 08:48

It's still a hub software problem, IMO. DC++ has no control over how the hub software reacts to the entreaty to reconnect automatically. It is how the hub in question is reading the command. Whatever hub this is happening with, it emphatically doesn't happen with all hubs. So the coder of whatever hub software you're trying to connect to would be well advised to read what you have said and determine why the automatic command is rejected but the manual command is listened to.

Gratch06 · Post by **Gratch06** » 2003-09-22 11:01

Lightning Man wrote:DC++ has no control over how the hub software reacts to the entreaty to reconnect automatically.

Reconnecting automatically is handled client side. The client initiates the conections, not the hub.

cyberal wrote:doesn't DC++ react to the "nick taken" string? If the hub would simply send another message, would the client still think his nick was taken?

DC++ reacts to the $ValidateDenide| command and adds its own nick taken message to the mainchat, so a simple hub "fix" wouldn't solve the issue.

gourmet wrote:no more messages in chat, no users list appeared, no hub invitation message, but I see downloads from other clients started

This would seem quite interesting to me, as the client has to see the user online (in the nicklist) before it can try to connect to them.

-Gratch06

Post by **GargoyleMT** » 2003-09-22 11:13

gourmet wrote:Of course I told about this. If nick is free - reconnection goes well. But if "nick was already taken" - then after time DC++ doesnt' reconnect to server but restarts downloading from users as well.

What hub software is this on? It's not OpenDC Hub, is it?

rexster · Post by **rexster** » 2003-12-11 07:48

having exactly same problems.

tried to connect to ptokax 0.3.3.0 and also 0.7.10 opendc hub
same problems happen.

so, i search for alternative clients and found dc++ 0.251 multe edition
somewhere in the net...
it solve my problem by reconnecting to the hub when getting
the nick taken message.

still...
it have to reconnect almost a dozen time before it get in with my nick.

if only a better solution???

maybe, automatically add some random number to the nick
before reconnecting??
so, the error shall never occur again...

Post by **GargoyleMT** » 2003-12-11 11:37

rexster wrote:tried to connect to ptokax 0.3.3.0 and also 0.7.10 opendc hub

OpenDC Hub? see this bug report (by me): http://sourceforge.net/tracker/index.ph ... tid=431657

maybe, automatically add some random number to the nick
before reconnecting??
so, the error shall never occur again...

No. This breaks queues, and is a feature that Arne specifically never copied from NMDC, which is the originator of the numeric suffixes for nicks.

rexster · Post by **rexster** » 2003-12-12 08:30

so. it's the opendc hub.
but, how about the ptokax?

anyway...
if a multe edition can reconnect, why dont dc++ implement this feature?

perhaps, a better solution is,
after getting a nick taken message, dc++ disconnect and wait a
longer time, perhaps 5minutes or more.
then, try reconnect again.

wouldnt this be a better solution???
it is from a user point of view...