FYI, I just found this iptables-based P2P detector: <http://www.ipp2p.org/> For those of you wanting to traffic-shape your BitTorrent users, install this "match module" on a Linux gateway and add an appropriate iptables rule to mark the P2P traffic, then shape it with tc.
Dear all, You see users of BT can set the maximum number of connections allowed. I am wondering whether BT will always set up that many connections when downloading. I mean that is it possible that my computer is not willing to serve that many peers since it is busy with something else. So it just uploads to one or two peers even though it is far from the maximum connections allowed and some others at the same time are asking for service from it. Thanks for reading. Bests, Tom
On 5 Jul 2005, at 11:09, Anthony wrote: > Dear all, > > You see users of BT can set the maximum number of connections allowed. > I am wondering whether BT will always set up that many connections > when downloading. I mean that is it possible that my computer is not > willing to serve that many peers since it is busy with something else. > So it just uploads to one or two peers even though it is far from the > maximum connections allowed and some others at the same time are > asking for service from it. > That seems unlikely, the number of connections that a computer can have is quite large. Are you sure that your computer is accepting connections from outside? How many others are in the torrent? Justin
I think I have not expressed myself clearly. My question is whether BT will always admits new requests as long as the max number of "upload" connections set by users has not been reached. For example, maybe I set the number of maximum upload connections allow is 4,as default, but BT only uploads to 2 peers, then stops and refuses to upload to others even though it is admitted to upload to 2 more peers. Is it possible? 2005/7/5, Justin Cormack <justin <at> street-vision.com>: > > On 5 Jul 2005, at 11:09, Anthony wrote: > > > Dear all, > > > > You see users of BT can set the maximum number of connections allowed. > > I am wondering whether BT will always set up that many connections > > when downloading. I mean that is it possible that my computer is not > > willing to serve that many peers since it is busy with something else. > > So it just uploads to one or two peers even though it is far from the > > maximum connections allowed and some others at the same time are > > asking for service from it. > > > > That seems unlikely, the number of connections that a computer can > have is quite large. > > Are you sure that your computer is accepting connections from > outside? How many others are in the torrent? > > Justin(Continue reading)
On 5 Jul 2005, at 12:56, Anthony wrote: > I think I have not expressed myself clearly. My question is whether BT > will always admits new requests as long as the max number of "upload" > connections set by users has not been reached. For example, maybe I > set the number of maximum upload connections allow is 4,as default, > but BT only uploads to 2 peers, then stops and refuses to upload to > others even though it is admitted to upload to 2 more peers. Is it > possible? > Ah I see. No for upload this wont be the case, as the tit-for-tat algorithm may say dont send these peers anything else until they send us more. This should sort itself out eventually though. Justin
>From: Edward Walker <walker.edward <at> gmail.com> > There are multiple ways to solve both problems, for example, the > controversial Merkle hash trees. I propose a different solution based on What is controversial are the precise details of /how/ they're implemented, not the choice to use them. > simple recursion. The solution is to distribute the .torrent via BitTorrent > as well and use one (or more) digest of the .torrent as identifier, as follows. > This is the exact same idea as Merkle trees. > 3. The short, secure file identifier SSFID of file F is now formed by the > concatenation of the digests found in meta torrent M. Why, when you're trying to stay similar to pure BitTorrent, are you introducing this ridiculous "SSFID" from nowhere? This doesn't gain you anything, and adds complexity. > The advantage of this solution is that it does not require any changes to > the BitTorrent protocol. A disadvantage is that it increases load on the > trackers somewhat. You've introduced this "SSFID", a very significant protocol change. Given the lack of anything to gain from this, why? Due to creating this, you cannot fallback to the strategy of manually telling your normal BT client to download the metatorrent and then the main torrent. There is little incentive for peers to keep with the metatorrent. Given(Continue reading)
> > What is controversial are the precise details of /how/ they're > implemented, not the choice to use them. > Hi. so do you think there will be agreement on a proposal soon? With authoritative Bram missing I think that's gonna be hard. This proposal is something that client developers can adopt without breaking backward compatibility. > > Why, when you're trying to stay similar to pure BitTorrent, are you > introducing this ridiculous "SSFID" from nowhere? This doesn't gain you > anything, and adds complexity. > Ultimately, I would like to have just BitTorrent URLs, which can then be supported by browsers natively, just as with ftp:// to improve usability (no need to install and update separate client, human transcribable) and it gets the Web servers for distributing the torrents out of the loop. > You've introduced this "SSFID", a very significant protocol change. Given > the lack of anything to gain from this, why? Due to creating this, you > cannot fallback to the strategy of manually telling your normal BT client > to download the metatorrent and then the main torrent. >(Continue reading)
Hi. I've completed initial FUSE support into my BitTorrent client. It allows users to mount a .torrent file as a file system, and then cd into it, cat/more/vi/cp files in it, etc. Files are only downloaded when requested. It's only lightly tested, and clearly in alpha stage. It's available at btslave.sf.net. It's kind of cool, but not hugely useful yet. To become much more useful, the BitTorrent protocol has to be extended/modified significantly to allow it to work well with lots of often changing small files, rather than a few static huge files. This would allow programs like YUM to work from torrents rather than FTP sites. If I find the time and motivation, I might work on such a project, but so far, there hasn't been much demand from potential users... I'll be out of town for all of next week, but I'll be able to offer any needed support after that. Bill
I was curious if anyone has experimented with a choking algorithm based primarily on network closeness, rather than transfer speeds? For many situations the close peers are going to be the fastest anyhow. But in some circumstances one might prefer a slower, closer peer than a faster, farther peer. Those circumstances probably amount to someone paying for Internet transit at a peering point. Any deployable implementation would need a heuristic, and maybe user tunable knobs, as to when to fall back to a fast, far peer. For certain very popular torrents on a very large 'internal' network, one can imagine a situation where the percent of the total filesize transiting an upstream network connection point for download approaches only 100%, perhaps a very significant reduction from the fastest-peer algorithm. I can see a good implementation causing an ISP to prefer BitTorrent traffic over HTTP traffic, since they're not going to be paying any transit costs on the local traffic. Anyway, this doesn't seem particularly clever, so I'm sure somebody's thought of it before, but I didn't find mention of it in the list archives. I'd appreciate any stories or pointers. Thanks, -Bill ----- Bill McGonigle, Owner Work: 603.448.4440(Continue reading)
On 11 Jul 2005, at 18:45, Bill McGonigle wrote: > > I was curious if anyone has experimented with a choking algorithm > based > primarily on network closeness, rather than transfer speeds? > > For many situations the close peers are going to be the fastest > anyhow. > But in some circumstances one might prefer a slower, closer peer > than > a faster, farther peer. Those circumstances probably amount to > someone > paying for Internet transit at a peering point. > It came up on the list before, and there were some uses for it. The main problem is that no one seems to have enough information to measure closeness, unless you actually work for a large ISP or run BGP. If some metric that could be made available to more developers could be found then some progress might be made... j
RSS Feed2 | |
|---|---|
1 | |
2 | |
3 | |
1 | |
2 | |
5 | |
1 | |
2 | |
14 | |
10 | |
8 | |
2 | |
3 | |
4 | |
3 | |
7 | |
6 | |
13 | |
8 | |
2 | |
22 | |
2 | |
14 | |
6 | |
5 | |
16 | |
13 | |
13 | |
5 | |
25 | |
1 | |
15 | |
5 | |
8 | |
7 | |
4 | |
19 | |
3 | |
2 | |
9 | |
12 | |
17 | |
40 | |
3 | |
4 | |
7 | |
34 | |
17 | |
7 | |
22 | |
31 | |
24 | |
19 | |
19 | |
20 | |
46 | |
25 | |
34 | |
57 | |
23 | |
14 | |
26 | |
47 | |
56 | |
11 | |
37 | |
63 | |
60 |
