overand

New thoughts! I was reading a thread: http://forum.bittorrent.com/topic/19214-trouble-with-rotuer/?p=50004 This seems to indicate that if your firewall / router 'renumbers' your outgoing connections (i.e. source port) that things will 'break' and you'll end up needing to connect through relays. IS THIS MY ISSUE? It may be! I can try disabling the renumbering via my Firewall (pfSense 2.x on both ends, in fact) - but this is Kinda A Problem. Lots of business firewalls do this for security, and no protocols that I've seen from the past 10 years have this sort of 'it doesn't work with renumbering' issue! SIP - sure, but SIP is a train wreck. I do think some 'paranoid' configurations of OpenVPN may have similar behavior, but seriously folks! This is not a sane way to handle networking in the year 2014 - you can't count on the outbound port of a client being a certain number! This is also fundamentally incompatible with having multiple clients behind NAT. Please get rid if this limitation, if that is in fact a current limitation.

This is a really interesting idea for static content. Unfortunately, I can't even begin to fathom a way for this to handle dynamic / scripted content - at least not 'server-side' scripted content. Still, a very interesting way to make static websites!

OK folks - "seasoned network administrator" here. I've been hoping to use BTSync to share some business-related files & directories from my employer's systems, to let their clients more easily access some data, etc. But I've run into an 'Unexpected behavior!' I set up the 'server' - Windows 2008 R2 with BTSync, and share the folder. I've also set a custom 'listen port' and performed a MANUAL NAT / port forward. When the client (who is behind NAT and is *not* supporting uPNP) connects, they get a low, low speed of around 50kilobytes/second, even though the client's download pipe is many, many times that, and the server's upload pipe is many times that as well. When reviewing the open connections on each end, I could see that the 'client' was in fact NOT connecting directly to the 'server.' Is there a reason that the 'relay' servers were being used, even though there was the ability for at least a one-way direct connection? (Yes, I've tested the direct connection, by telnetting to the remote system on the custom port, and I was able to establish a connection). The configuration is fairly normal. Both systems are behind NAT firewalls. The "server" has the custom BTSync port forwarded to it. The expected behavior - direct connection from 'client' to 'server' did not happen. Why? I'm confused. Also, in the logs, I saw the following unexpected entries. Note that port "34780" is *not* the port I used - I in fact specified port 61223 - the 'lan port' it's trying to connect to is the right one, but the port it's trying to connect on the actual WAN interface is very wrong! [2014-02-13 12:59:01.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:01.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:02.296] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:02.296] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:02.296] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:02.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:02.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:03.296] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:03.296] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:03.296] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:03.296] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:03.296] ping yyLAN.IPyy.63.13:61223 peer local address[2014-02-13 12:59:04.297] Sending broadcast ping for share 5678obfuscatedshare500[2014-02-13 12:59:04.297] Sending broadcast ping for share 0123ObfucsatedShare012300071[2014-02-13 12:59:04.297] Send ping to peer (01234567obfuscatedpeer000C99) for share 0123ObfucsatedShare012300071:[2014-02-13 12:59:04.297] ping xxWAN.IPxx.253.205:34780 directly[2014-02-13 12:59:04.297] ping xxWAN.IPxx.253.205:34780 via relay[2014-02-13 12:59:04.297] ping yyLAN.IPyy.63.13:61223 peer local address

I'll add my own voice to this: An open source version would be nice and all, but what's far more important? Make BTSync an OPEN PROTOCOL / STANDARD! Keep the "BTSync" application itself propretary (and free), but open up the documentation / design of the BTSync protocol - and let other folks make their own BTSync clients! Of course, this means that there will potentially be interoperability headaches, but this will improve the market penetration of BTSync because the open source folks will be more inclined to use the protocol, and the 'don't care' folks will be GLAD to use the tried-and-true official BitTorrent.com BTSync application! Please, please - this before 'open source.'