Request: Additional timer for creating port mappings

Bug #1269933 reported by Charlie
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AirDC++
New
Undecided
Unassigned
DC++
New
Wishlist
Unassigned

Bug Description

There are more and more passive users around. Many of these users use the settings for automatically create the port mappings at startup. It happens, more often nowadays, that the mappings fail due to whatever reasons without any changes to the client/router. Users often fix this by restarting either client/computer/router. What if there was a timer (in addition to the port mapping) that would enable the client to retry the mapping every X s/m/h or something?

Version: AirDC++ 2.70a-123-g8b45f-d

Br Charlie

Revision history for this message
LoRenZo (lorenzo-mailbox-deactivatedaccount) wrote :

I believe this is sort of related to what I wanted to request.
I am getting the following every once in a while for a couple of hubs:

[17:54] <BOT> Your search IP is not <INTERNAL IP> but <EXTERNAL IP>.
[17:54] *** Connection closed

Reconnecting to the specific hub right away solves the issue from what I can tell.
I believe that being automatically connected to numerous hubs when the client starts up might be responsible for this.
I was thinking of having a small delay between the port mappings and the automatically initiated connections towards the favorite/saved state hubs.

I am using the lastest available revision of DC++ 0.831, but I saw this in case of older revisions of the same client as well.

Revision history for this message
Fredrik Ullner (ullner) wrote :

This patch adds the aforementioned setting, set to 60 minutes as default. I suppose one might consider a smarter implementation (set timer to 2 minutes after, increase timer with 2 minutes each time it fails etc), but I didn't bother with that.

Note that I put this in the experts only category, since it isn't something that most people will need to use, I feel.

Revision history for this message
eMTee (realprogger) wrote :

I think it would be better to decide first that if there's anything to fix here at all.

First of all I'd beg to differ to the reporter as since the Automatic Connectivity Setup introduced the amount of passive users in DC network (and along with it, the support requests about connection problems) has been definitely lowered.

Secondly, I fail to see how periodic port mapping re-attempts would result much more active users. If the port mapping fails for the first try it's unlikely it'll succeed for any subsequent tries.

Moreover if the search/download doesn't work, the user won't wait for 30/60/whatever minutes, rather they'll do some action a lot sooner which, in almost all cases, includes a client restart. If the user restarts the client/OS then the required redetect will happen at the next start.

And at last but not least, while the case in comment #1 is not related to this report (it's more likely because of a delayed $UserIP procesing due to the excessive resource demand of auto-connecting to extremly large amount of hubs - and the problem goes away automatically after the sent IP is processed), timely redoing the connection detection possibly results just that exact confusing error message in some hub/script usage scenarios.

So I guess it needs some more thinking of what we can gain and what to lose with this new feature.

Revision history for this message
poy (poy) wrote :

i would like the setting mentioned in comment #1.

connectivity retries i am more dubious of, however; eMTee has explained the reasons. this will require extensive real-world testing if we really want to have it in.

specific point about the patch: don't set autoDetected = false after passive mode has been "auto-detected". the autoDetected variable is not meant to signify active mode success but only that auto-detection has ended. it has other uses, for ex in the status message obtained with "/conn". either add another flag for active mode success or just use autoSettings[SettingsManager::INCOMING_CONNECTIONS].

Revision history for this message
Night (night.) wrote :

As a side comment for my own experience, i use the autodetect connection, and it sometimes fails at startup.. But when it fails it doesnt help if i restart the client or even restart windows. In my cases restarting the router allways helps and sometimes manually removing the portmappings from the router. So atleast in my case any kind of timer would not help to get the active mode working again, Im not saying there cant be cases where it helps, but if the mapping fails at startup I agree with eMTee, the user will restart client/windows/router in order to get it working, atleast I would not wait for a period of time for it to try mapping again and in my case it will also fail again with each try.

Fredrik Ullner (ullner)
Changed in dcplusplus:
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.