VexTV introduces multisourced downloads to OpenNap

[TankGirl]

VexTV is one of the less known OpenNap clients. They have just released a version (0.50) with multisourcing capabilities, claiming it works also over different OpenNap networks. The client itself is very small (only 140 k) and uses web-style interface which is probably (haven't yet tried it myself) much less sophisticated than WinMX or audioGnome but some commentors seem to like it. Anyway, this is an interesting technological step and I wish that e.g. WinMX would also consider supporting multisourcing on OpenNap.

See also the comments on Zeropaid.

- tg

[assorted]

Thanks for the good tip.

If it works, it's stable and easily allows updating of the Opennap list it could lure me back to Opennap. With Morpheus down the whole thing is up for grabs now; hehe.

[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.

[TankGirl]

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

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