BearNotes

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.

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

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?