BearNotes

How about adding smething like this to the spec?

The Client must support file resuming and Bit Torrent style multiple feeds.

Yes, they include the requestor in the message. Either way, the list of Neighbors has to be trimmed, from the requestee or requestor.
Both methods have their pros and cons, and we chose this method.

Jason and Kirk

In this case there is nothing else to do but not return a peer. We have updated the specification to include this case. The solution is to respond with an empty PEER message which is as follows: PEER * This message will validate the RQST or JOIN message, but also indicate that that client has no pee...

This is also a case of file names existing as unique identifiers. But also, the protocol specifies that the FILE message must include the file size, offset from the beginning, segment length, and the filename. NOTE: It will be up to the client to maintain some sort of data that indicates the portion...

This is true, but for this project we are working under the assumption that a filename uniquely identifies a file. If this were not the case, then other identification measures would be necessary as you have stated.

-Jason

We purposefully left the first RESULT message fairly ambiguous, for two primary reasons. (1) we did not think that parsing a newline character would be any more difficult than parsing any other path. (2) since the protocol specifies that the first client that can fulfill a file request must handle t...

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