I propose a new network by slightly modifying the gnutella protocol. here is my vision of how this new network could be realized:

all servants are hard coded to share.

all files are viewed programmatically as chunkable into 20 equal parts

no servant ever shares more than 50% of a file to any one servant.

no servant ever knows who is the final recipient of the portion of data being transfered.

protocol headers remain unmodified from the gnutella headers.

ping, pong remain intact. routed as normal

queries modified:
byte 0+ = search string (null terminated).

routed as normal.


queryhits modified:
byte 0 = number of items found
byte 2+ list of items found (null terminated)

list of items:
bytes 0 = filepart
bytes 1-4 = filesize
bytes 5+ = The pathname of the found file. (double null terminated).
last 20 bytes = hash of the found file. (double null terminated).

routed as normal

add a datarequest descriptor:
byte 0 = filepart
byte 1-20 = filehash

routed similar to a query, ie. Rebroadcast packet through every available connection, except the one from which it was received.

add a datatransfer descriptor
byte 0 = filepart
byte 1-20 = filehash
byte 21-24 = datalength
byte 25+ = data

routed similar to a queryhit ie... Forward packet only through the connection from which the datarequest came.

messageid from datarequest is inserted into datatransfer header to facilitate transfer back to requestor.

in this case a servant seeing this messageid will have to check if the descriptor is a datarequest or datatransfer, if it is a datarequest and it has seen the messageid it can safely eat the packet. if it is a datatransfer, it passes the packet back to the servant it recieved the datarequest from.

all servant will maintain two data folders, one to store the files that are used but can have chunks copied from, the other to store datatransfer packets recieved. these 'packets' are stored in the folder only until it is sent back on its way or if for some reason not retransmitted it is deleted 48hrs later.

i know that this will cause the servant to eat bandwidth by upload/download of datatransfer packets but i think by splitting a file into 20 equal chunks it will make it bearable.

ttl should also be changed to minutes to live (2-3?), and hops not used for datarequset and datatransfer packets so that the preceeding servant has no way to tell by checking ttl where the datarequset came from, ie. if the servant saw this messageid greater than 3 minutes ago and the max 'mtl' is set to 2 it would then eat the packet and not forward it. the main reason is so that the first servant receiving the datarequest could not surmize that the request came from the connected servant if the ttl was 7 and hops was 0. it would only see a 'mtl' of x

another way might be to just increase the ttl and hops to say 15-25 and the originator of the datarequest or datatransfer would fill the ttl and hops with a random low number, this is just to keep the first servant on either side from telling where the packet originated from.

the ultimate reason for this new protocol is so that no servant 'knows' where the data/request came from or where it is going.

I know that this is extremely rough and quite possibley unfeasable for many reasons, and by far no rule as to how to do it. but it's just a thought... don't bash me to hard.