Max Number Of Users For A Shared Folder

[jpw3]

Is there a maximum number of users I can share/sync a folder with using BTSync?  I'm looking for either a hard limit (ie, BT sets a limit) or else a practical limit (ie, performance drops off dramatically when a folder is shared with more than X number of users).  I would be interested in any limits both for the Free and Pro versions.

 

The background to my question is that we are developing a private content delivery network utilizing file sharing services, and wanted to check how scalable file sharing is with BTSync.

 

Thank you very much for your input!

 

John

[Helen]

John,

 

You can share a folder with unlimited # of peers, but first 100 peers can be connected and syncing folder at a time. Others, will have to wait till any of those 100 will go offline. 

 

Sync relies on p2p technology as you know. So if there are slow peers in the mesh it can slow things down, just like quick peers can increase speed of syncing. But there are no strict dependencies like "performance will drop twice if you share with more than X peers". 

[jpw3]

Thank you, Helen - this is very helpful!

 

John

[BobAchgill]

Is there a que such that the 101st peer that is waiting to be part of the sync is push notified when it can join in the sync once the active peer count reduces to 99?

Or do the 1000 peers waiting for a place in the 100 active peer status have to keep asking to be let in?

What if the original seed computer is turned off and among the 100 active peers there is not a complete assortment of the folder data... does the torrent stall... or will they let in a seed peer that has the missing data to complete the missing data??

[Helen]

BobAchgill,

As was mentioned "Others, will have to wait till any of those 100 will go offline. "

So you can give the link/key to any number of peers, they won't connect, and will be waiting in the queue, till anyone of those 100 currently connected peers goes offline. Then the first peers in queue will take the freed place.

if the only peer who has all the pieces of file disconnects (original seeder), others will not be able to upload the whole file - they don't have it yet. They'll upload only those pieces they have. It's peer-to-peer network.

But if anyone managed to download the whole file and then original seeder disconnects, that 'anyone' will continue uploading the file to others.

[BobAchgill]

Helen,

Is there a chance that the 100 max number of users for a shared folder could be increased in the future?  Say 1,000?  Or maybe let shares have a specified share time allotment and at the end of their time they have to go back to the end of the line and wait their turn to share again?

Tks!

[iswrong]

Is this an artificial limitation (e.g. to avoid Sync being used for illegal file sharing) or a technical one? (Sync's relay servers or trackers wouldn't be able to handle the load.)

[BobAchgill]

I am going to distribute my copyrighted literacy material in Africa to 100++ folks soon and I want to know how the 100 limitation will affect the distribution. Since its hard to test that scenario myself to know how BTS will handle it.

Like do I need to tell the recipients something like "Once you have all the files please close your phone or computer so others can receive their copy"??

...Or will BTS understand that those 100 are fully synced and push them offline to allow the next 100 online to get their copy of the files?

tks!

[Helen]

The thing is that Sync was initially designed for home and small office usage, with pretty little chance for a household having more than 100 devices. Sync was not and is not designed for public sharing of files.  Thus this limitation.

No, Sync cannot push the fully synced peers offline. This needs to be done manually: those who got the files shall go offline themselves. Or, if this is a single delivery and they won't need to sync files from this share anymore, remove the share from their device. 
 

[BobAchgill]

6 hours ago, Helen said:

The thing is that Sync was initially designed for home and small office usage, with pretty little chance for a household having more than 100 devices. Sync was not and is not designed for public sharing of files.  Thus this limitation.

No, Sync cannot push the fully synced peers offline. This needs to be done manually: those who got the files shall go offline themselves. Or, if this is a single delivery and they won't need to sync files from this share anymore, remove the share from their device. 
 

There is no need to be apologetic that by adding in the public share feature your developers bested Dropbox's share feature on steroids... simply because DB has the daily bandwidth limit.  I can see those developers high fiving even now.

ok, for now I will resort to manually pushing already synced shares offline using the technique ...

GreatMarko"Yes, temporarily setting peer_expiration_days to "0" will clear cached peers."

What is the limit of the queue of those waiting to get in to share?  Does that "waiting to share" queue get destroyed when manually flushing the synced peers?

 

 

[BobAchgill]

Can I use the API to do the manual flush to... temporarily set the peer_expiration_days to "0" to clear the cached peers?

[Helen]

there is no limit to those who wait. Though more pending peers will result in higher network activity and will affect performance and CPU. So it's advisable to flush the cached peers every now and then. 
Yes, you can use API for that 

[BobAchgill]

Does that "waiting to share" queue get destroyed when manually flushing the synced peers?  If so then what determines who is first in line once the pending peers queue is re-established?

[Helen]

16 hours ago, BobAchgill said:

Does that "waiting to share" queue get destroyed when manually flushing the synced peers?

yes. 
The first who was able to establish either TCP or UDP channel with your  computer will be the first in line.

[BobAchgill]

Is the 100 max active shares at a given time tied to the link that they shared to get to the folder or to the folder itself?  I recognize that to make and send out a share link for a folder that all links made are different even though they point to the same folder.  Hence my question.

 

If the 100 max active shares is tied to the individual links (and not the folder itself) then could a person just send out lots of links for the same folder to up the effective number of users sharing to a single folder.  If this were true then the max number of people having share access to a given folder would be  [100 x #number of share links]??

[iswrong]

It's a limit per folder.

[AuroraUK]

On 9/16/2016 at 5:22 PM, BobAchgill said:

There is no need to be apologetic that by adding in the public share feature your developers bested Dropbox's share feature on steroids... simply because DB has the daily bandwidth limit.  I can see those developers high fiving even now.

ok, for now I will resort to manually pushing already synced shares offline using the technique ...

GreatMarko"Yes, temporarily setting peer_expiration_days to "0" will clear cached peers."

What is the limit of the queue of those waiting to get in to share?  Does that "waiting to share" queue get destroyed when manually flushing the synced peers?

 

 

You should research as much as possible, before jumping into it, or get an expert, who can help with your cycle design, so that you can have the best possible results, with the smallest amount of gear https://jbhnews.com/dianabol-dbol-methandrostenolone-steroid-review-for-bodybuilding/27503/.

The physiques and results that are desired by most average people can easily be achieved with “sports TRT” doses (250–350 mg/week gear). You have to remember, that steroid usage is a marathon. Everyone wants results now, but if you want to reach your best self, with minimal to no harm, then you have to think long term.