Quote:
Originally posted by pod
The site is very scarce on details, but the reason no OpenNAP clients supports multisourcing is that the underlying protocol does not support it. Unlike Gnutella, OpenNAP has resisted proprietary/incompatible extensions so far, and I imagine that's exactly what these guys did; I bet you can only multicource from other same clients.
Not that it's a bad idea, just that it's not likely to succeed.
|
It is true that multisourcing has not been explicitely supported (or even thought of) in the Nap/OpenNap
protocols but resuming is and I think that opens up a way to implement multisourcing from any existing Nap clients with resume capability. The desired offset of the download is part of all download requests - for fresh downloads it is zero and for resume requests it is non-zero, marking the point within the file where you want to start resuming from. The protocol does not explicitely support any blocksizes in segmented downloads but the client can always cancel the transfer as soon as it has received what it wanted.
As for finding multiple sources for a particular file, the command
Quote:
215 (0xd7) request resume [CLIENT]
<checksum> <filesize>
client is requesting a list of all users which have the file with the characteristics. the server responds with a list of 216 messages for each match, followed by a 217 message to terminate the list.
|
seems to provide a handy way to get them from the servers.
- tg
