UPnP support in tinc

[Etienne Dechamps]

On 11 November 2015 at 21:57, David Nicol <davidnicol at gmail.com> wrote:
> it is entirely possible to write code that uses threads on Win32 and forks
> on POSIX by abstracting the communication bits generically. Signalling could
> work over pipes on both.
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx

Hum... yes of course, but I don't see how that addresses my concern.

My point was, we either need to do something different between Win32
and POSIX (whether that implies different thread APIs or different
process models is besides the point), which means we'll end up with
#ifdefs (which is not great, because that makes code harder to
maintain). Or we add a dependency on pthreads-win32 on Windows so that
we can write the same code on both platforms. It's mostly a matter of
taste really. (Personally I'm leaning towards the latter.)

I'm not really concerned with communication. In fact I'm pretty sure
the UPnP thread wouldn't have to communicate with tinc at all: it's
pretty much a fire-and-forget affair. The UPnP code would only need to
know which ports to forward, a parameter that can be provided at
thread start. Afterwards, the thread would just keep the UPnP mapping
alive indefinitely without having to talk to tinc at all. Therefore
there's no need for pipes.

(I realize that this means UPnP support could possibly be achieved
simply by suggesting that the user spawn some standalone UPnP client
process in the background from the tinc-up hook. That's not very
user-friendly, though. Especially on Windows.)