On Aug 6, 2012, at 4:00 PM, Sampsa Laine wrote: On 6 Aug 2012, at 20:07, Johnny Billquist wrote: Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack. As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously. My desire for this is basically because my ISP is NAT'd to hell - I have no way of getting UDP packets back to my network, as the ISP gives me a non-routable address. Why go with this ISP? Well it's about 3x faster than the DSL I can get in the sticks over a 3G signal, with unlimited bandwidth and usage. But sucks for HECnet.. Is there any protocol/port at all that you can get, inbound? Or are you limited to outbound connections only? For outbound, are there any significant limitations on what ports you can use? Ethernet tunneling over TCP seems reasonable enough, even though the TCP connection/ack machinery is pure overhead for this application. SSL could be used if security is needed -- is that important? For people who have port number limitations (censoring ISPs) I wonder if tunneling over HTTP should be defined. :-), sort of. And for things like SSL... I should have thought of this earlier, but it occurs to me that a "user mode router" could nicely and easily be implemented in Python. Lots of bits of algorithm get very simple then; for example, turning on SSL support takes only a couple of lines once you have a non-SSL protocol implementation. And of course it runs on lots of operating systems without any change being required, even Windows. And yes, it supports threading (very easily). paul