[p2p-hackers] Real-world UPnP stats
ap at hamachi.cc
Mon Jun 19 18:53:43 UTC 2006
David Barrett wrote:
> On the topic of UPnP, does anyone have any advice on whether to use the
> IUPnPNAT interface in Win32 versus going straight to the UPnP layer?
Stay as far away from IUPnPNAT as possible. This bundle of joy tends
to randomly fail perfectly valid requests with undocumented return
codes. It also depends on SSDP service, which is frequently painted
as a major security hole and therefore scares users off.
> As I understand it, IUPnPNAT is a wrapper/helper atop the lower-level UPnP
> interfaces. Is there any advantage to going with the low-level route versus
> sticking with the helper?
> Alternatively, Alex, how difficult did you find it to write your own UPnP
> code from scratch?
It took me a couple of days to write everything from scratch (zero
external dependencies), but that clearly depends on your development
style and experience.
> And finally, does anybody use UPnP for anything other than NAT port mapping?
> Can you, for example, query a gateway's realtime bandwidth usage using UPnP
>> -----Original Message-----
>> From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org] On
>> Behalf Of Saikat Guha
>> Sent: Monday, June 05, 2006 7:24 AM
>> To: Peer-to-peer development.
>> Subject: Re: [p2p-hackers] Real-world UPnP stats
>> On Mon, 2006-04-24 at 11:56 -0700, Alex Pankratov wrote:
>>> We've recently added UPnP support to our client software and
>>> now I got some server-side stats and they are most interesting.
>>> Check this out -
>>> Roughly a half of all clients that reported success talking to
>>> their 'routers' and establishing TCP/UDP port mappings were
>>> still inaccessible from an outside via their mapped ports.
>> Interesting. Some reasons for this I can think of are as follows:
>> - If I recall, UPnP on a NAT that is behind yet another NAT doesn't work
>> well (since the UPnP Internet Gateway Device on most NATs
>> typically doesn't act as a client for the outer NAT's UPnP IGD). This
>> comes into play when some connects a wireless router to their existing
>> wired-only NAT or something.
>> - UPnP doesn't have nice crash semantics. If an application registers a
>> mapping, crashes, is restarted, and re-registers the same mapping, some
>> NATs ignore the new registration while other NATs silently reap the old
>> mapping. The first case would result in broken behavior.
>> - On the flip side, if two different applications register the same
>> mapping, the latter mapping may silently override the former mapping or
>> alternatively, the latter may get silently ignored. Either way, one of
>> the applications suffers.
>>> Anyone care to comment or compare this to their own numbers ?
>> While I don't have numbers, I suspect UPnP success rate (for NATs that
>> support UPnP) would depend on the application as well as the topology
>> common for the target user population.
>> As a side note, if you want to test UPnP functionality, target Japanese
>> users -- based on anecdotal evidence, UPnP seems far more popular in the
>> far east than anywhere else.
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> Here is a web page listing P2P Conferences:
More information about the P2p-hackers