Multiple connections to the same peer

Peer-to-Peer discussion group for CSC 445

Moderator: jaf656s

Matt Collins

Multiple connections to the same peer

Post by Matt Collins »

Just to make it seem like this board is full of activity, I'm going to post another idea.

Should there be more than one connection to a peer? The purpose of this would be to set up a socket for downloading/uploading while leaving another socket for general network activity/searches. It wouldn't be a very good thing if a user was downloading 5 files, thus using up every peer, and could no longer search because the connection was being used up by the download.

It might be a little tougher to maintain the connections, but it seems like it should probably be that we establish a whole new socket for every download. Any thoughts?
jaf656s
Bear
Posts: 7
Joined: March 9, 2005, 11:16 pm

Post by jaf656s »

This issue is covered in the specification, section 3.B,
... This message should be sent to the listening port of the requesting peer, creating a new socket for file transfer and leaving the control socket open for message traffic. ...

Jason
User avatar
Paco103
Single White Admin
Posts: 629
Joined: January 15, 2004, 9:22 pm
Location: Right Here
Contact:

Post by Paco103 »

That idea is already implemented, and it actually solves several problems that existed. For one, as you mentioned, downloading will not effect the standard network traffic, and also for disconnections and pruning. If a peer wants to prune and disconnect from a peer, we determined this could not be done if a file transfer was active. We were worried about having some way to initiate a pending disconnect and to make sure no new information was exchanged, allowing the connection to eventually be terminated. By using a seperate socket for the file transfer, a prune can work regardless of current connection status. The control connection can be broken, therefore completing the prune at any time, but any currently active trasfers will not be effected due to the seperate file socket.

Thanks for bringing that up though, that was one of our later implementations that we almost missed.
Post Reply