Jump to content

Negotiator mode


mcaspi

Recommended Posts

Assume a peer (not a seed) that has finished download and upload everything it wanted. Today it disconnects from other peers and seeds and doesn't contribute more to existing peers in the swarm. What I suggest is that if this peer wishes to be a negotiator, it will download data that peers in the swarm need and store in ram. The negotiator will then upload the data to other peers in the swarm. In my opinion, data transfer in swarms will be faster this way because if one route is slow for some reason, the negotiator route might be faster.

Link to comment
Share on other sites

because if one route is slow for some reason, the negotiator route might be faster.
So you want to rewrite the protocol to use "least cost" routing at the expense of 'bogging a client down' by caching data that "might" be wanted by another client?
The negotiator will then upload the data to other peers in the swarm
Not quite with you on this, are you suggesting that the client starts to "push" the data at the other peers regardless of whether that piece is required or not?
Link to comment
Share on other sites

How will any peer identify what pieces other peers require to be able to have those pieces ready?? There are no "can you find piece nnnnn for me" peer to peer messages?

Basically your proposal is that a peer should download ALL pieces regardless of "skipped" files.

It strikes me that you do not fully grasp the workings of the bittorrent protocol otherwise you would probably realise that what you are suggesting is pretty much already covered by using DHT and PEX

Link to comment
Share on other sites

My proposal is that a negotiator will download only requested pieces and not ALL pieces.
Yes I get that, but as above, unless a peer actually HAS that piece it will NOT receive any requests.

A client does not broadcast a piece request to ALL peers in the swarm, which is why I asked;

How will any peer identify what pieces other peers require to be able to have those pieces ready??

Basically what you seem to be suggesting is that each peer should function as a tracker as well as a uploading or seeding peer.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...