Links

 

 

Gnutella – The Basic Ideas

 

  1. It’s a protocol, not a product
    1. Different clients exist, so each client must either trust or verify
  2. Guiding Idea …. no central server
    1. Legal reasons
    2. Commercial reasons .. In the beginning there was no one to pay for the central server.
    3. Instead, they have a amorphous network
  3. Other Guiding Idea .. Anyonyity
    1. They will lose network performance to get this

 

 

The Protocol

 

  1. MessageID, 16 bytes - A unique identifier used for tracking this specific packet. It should be unique to the network, which is to say that two servents may not generate the same MessageID (within a reasonable amount of time), and one servent should never use the same MessageID more than once.
  2. FunctionID, 1 byte - The underlying point of the message. Labels the packet as a search, or a connection announcement (initialization), etc.
  3. RemainingTTL, 1 byte - The TTL left to this packet. The originating servent sets this and each servent the packet is routed through decrements it. See TTL.
  4. HopsTaken, 1 byte - The number of servents this packet has already been routed through. This starts at 0 and is incremented by each servent.
  5. DataLength, 4 bytes - The size of the remaining data in the packet. Included so that the processing servent will know when the incoming packet ends.

 

Loging onto Gnutella

 

1.      Find anyone on the gnutella network.

a.       How .. anyway you want (probably a cache)

b.      There are central servers (one run by limewire and bearshare)

2.      Send that person an init packet

a.       They send a reply

b.      They announce to their neighbors

c.       Who reply not to the source, but to the nearest neighbor

                                                                           i.      Slows network

                                                                         ii.      Provides anymity

1.      But hops-taken count helps make some guesses

2.      Unless the forwarder lies

d.      Only reply once

                                                                           i.      Must keep track of duplicate messages

                                                                         ii.      MessageID is unique, especially when combined with Host and Port and FunctionID

Searching

            Same idea as logging on

                        You send to neighbors, who send to neighbors, etc

                        No particular search syntax, so ‘.mp3’ might mean anything

                                    But if bearshare and limewire  agree, people will probably notice

            Note answer does not come from the possessor of the file

            Each servent can point to a unique file on a unique host

Caching

When someone connects, search *.*

Answer querries for them, don’t forward querries

            Works because you can send a reply naming a file on a different servent

How to stop bad servents

            Ban neighbors who supply bad data

                        But bad data will get to you anyway

            Propogate bannings

                        Need a crypto-strong way of establishing ‘trust’

 

Ping-Pong

            Pings can use 50% of gnutella bandwidth

            Just cache the pongs

            Only send pong if not firewalled and willing to accept a new connection

            Multiplex pings and demultiplex pongs

            only send the best pong

                        but what’s best??