UPnP errors: AttributeError: Router instance has no attribute 'location' #1131
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-20#1131
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Getting these errors while router says "Turn UPnP On":
I know that we worked on UPnP issues before, and UPnP worked perfectly afterwards, but that was with a different router. So this isn't necessarily a regression.
Router: Netgear WNR1000
Version: 0.6.3.2
OS: FreeBSD 11.1
Existence of such issue makes me think again that using proprietary code to do UPnP was a bad idea and you should use https://pypi.python.org/pypi/UPnP or https://pypi.python.org/pypi/miniupnpc instead.
The thing is, I want to move the UPnP code to asyncore as well. That may not mean I can't reuse an existing UPnP library but it's probably going to be more difficult.
You want to have UPnP processed in the same event loop? IMO, this has little benefit because UPnP is a really low traffic protocol. This will be more of a problem than a solution.
Threads in python seem to consume a lot of memory, the purpose of this decision is to save memory.
I don't think you need threads for UPnP. UPnP actions are rare and instant. This can be done from other threads.
It doesn't need many resources, however some operations can block. Most of the other code I saw was synchronous so I can't use it in a thread with something else.
Just run UPnP in the separate thread as an exception. Mostly major BM threads were consuming resources. There is no need to be overly-aggressive and eliminate every thread there is, IMO. -)
There is value in reusing code. Like this issue wouldn't even have been created had UPnP been handled by the external library.
Yes, that's still an option, a more urgent candidate for moving to asyncore is the DNS bootstrap.
I have an idea what can be done with my limited time. I'll make it so that if you have one of the modules you mentioned, it will try to use those instead of the built in. That I should be able to do rather quickly, then later I can add proper dependencies checking into setup.py and so on, but at least you'd be able to work around it simply by installing the modules.
Ok, I will add it as RUN_DEPENDS then.