Search the Community

I works behind proxy that allow connect only to 80 (http) and 443 (https) ports. I see that https://config.resilio.com/sync.conf does not contain any tracker or relay with http (80) or https (443) ports. How can I connect to my shares at work with such proxy?

One feature we LOVE about Dropbox and miss on BTSync is the ability to share a link to a single file that a user (not equipped with Dropbox) could open in their browser. I'm guessing your architecture makes this very difficult, even though you are providing a http server - I'm guessing that while I can access a client via http at for example http://192.168.1.34:8888/gui/ that this is not being exposed through UPnP/IGD and that therefore it would be hard to add the ability to retrieve files from its http server (in a similar way to Dropbox). Such exposure would be useful in other respects - for example to allow us to administer a BTSync client remotely, (for example to add a new share to a client that sits on a LAN at a different location, or to login and pick up the secret of a new share that I want to add to my laptop.) Blue sky-ing, the ideal feature would be a URL that resolved to any of a multiple of BTSynced devices depending on which was online at the time :-)

Request Headers. Note Accept. GET /api?method=get_folders HTTP/1.1Accept: application/jsonAccept-Encoding: gzip, deflate, compressAuthorization: Basic ASDFgfdsghstFDASGFDAGRADContent-Type: application/json; charset=utf-8Host: wintermute:8888User-Agent: HTTPie/0.8.0Response Headers. Note Content-Type. HTTP/1.1 200 OKCache-Control: no-cacheConnection: keep-aliveContent-Length: 654Content-Type: text/javascriptContent-Type should obviously be application/json -- we are not returning arbitrary JavaScript (aka JSONP) here. This should be fixed because: 1. sent content-type should match the requested type within reason 2. it's clearly application/json data being returned anyway 3. downstream APIs and tools may not handle text/javascript in the same way This specific example taken from FreeBSD 10.0 client. I'd suggest also you may want to consider including the btsync version in the returned headers. This will be useful in future for feature detection and operations.

I work for a small research company that makes educational software/games, and we've got a deployment of 50 computers in 10+ schools. We're currently synchronizing our application and media content from our server to the schools, and our log files from the schools to our server using SyncBack (FTP, yes I know -- without the S, no need to lecture). The schools have varying and inconsistent firewall rules, so the sync isn't happening at some locations. I know the limitations of the networks and why the transfers aren't working, so I'm not asking how to get through the firewall limitations This question is more to determine if btsync can get through strict firewall rules. Some locations allow FTP, SSH, SFTP, HTTP, and others are locked down to just HTTP. I've tried using WinSCP instead of SyncBack and tunneling SSH over HTTP using Aache mod_proxy, but even this is detected at some sites as a malicious proxy attack. At some sites we do not have the ability to open firewall ports. We need a synchronization solution that will work given these restrictions. Is btsync capable of handling this scenario? What ports does btsync use, what protocols for establishing the network (peer detection) and what protocol and ports for data transfer? Basically in the worst case all data needs to be transferred over HTTP protocol, and *not* using HTTP connect (e.g., Apache's mod_proxy ). In the best case the school is "wide open." I think btsync will work great for us, as it will limit the external bandwidth since not all 10 computers at each site will need to download the application updates. One can do the external download and the peers can sync from that "master" and from each other. In the worst case scenario that the school is completely shut off from the world, we could upgrade just by stopping by with an updated laptop and btsync would propagate all the changes to the peers on the LAN. I'd like to avoid that if possible. Thanks in advance! cm p.s. One of my alternative deployment solutions is using git to deploy the application (like Heroku uses). This should work since git has an HTTP protocol for pulling. The downsides are that we have a *lot* of data in our application/media and don't need/want to store the version history/deltas (in my tests the initial repo was about 1.8x as large as the folder hierarchy); and all the clients would have to pull all the changes, hogging network bandwidth.