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).aspxHum... 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.)
Etienne Dechamps <etienne at edechamps.fr> writes:> (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.)something like this :P https://github.com/LibreVPN/librevpn/blob/develop/lib/skel/scripts/port-forwarding -- :O -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 584 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151111/82bc8a02/attachment.sig>
fauno <fauno at kiwwwi.com.ar> writes:> Etienne Dechamps <etienne at edechamps.fr> writes: >> (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.) > > something like this :P > > https://github.com/LibreVPN/librevpn/blob/develop/lib/skel/scripts/port-forwardingbtw, +1 for tinc to support upnp, nat-pmp and even stun :) -- :O -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 584 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151111/6d4a8084/attachment.sig>
On 12 November 2015 at 01:15, fauno <fauno at kiwwwi.com.ar> wrote:> Etienne Dechamps <etienne at edechamps.fr> writes: >> (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.) > > something like this :P > > https://github.com/LibreVPN/librevpn/blob/develop/lib/skel/scripts/port-forwardingUnless I'm missing something, the problem with that script is that it won't keep the mapping alive. If the home router expires the mapping after a while (which is bound to happen, otherwise it would end up with accumulating garbage) or resets, there's nothing to "refresh" it. Ideally, one would want a daemon (or at least some kind of periodic event) that keeps refreshing the mapping (like every minute or so). Which at best would be annoying to manage (on POSIX), or at worse would be a PITA (on Windows). Hence my suggestion to integrate it directly into tincd.