Loading ...
Sorry, an error occurred while loading the content.

Re: G2 Network Approaching 100K Concurrent

Expand Messages
  • Raphael_Manfredi@pobox.com
    ... Hey, you were telling Anenga that he was wrong speaking for Mike. Please, don t speak for me. ;-) You re not totally wrong however in your demands. ...
    Message 1 of 65 , Nov 22, 2002
      Quoting Vinnie <info@...> from ml.gnutella.dev-forum:
      :To do any less is dishonorable, and worthy of the scorn of every
      :upstanding member of the GDF.

      Hey, you were telling Anenga that he was wrong speaking for Mike.
      Please, don't speak for me. ;-)

      You're not totally wrong however in your demands.

      :Let me repeat, Mike should

      Let me rephrase. Mike should:

      :1) Surrender Gnutella2.com and the Gnutella2 / G2 moniker

      Gracefully hand back the gnutella2.com domain to the community and
      stop using the Gnutella2 / G2 names when speaking about his new protocol.

      Indeed, the name Gnutella2 sounds like an official evolution of the
      Gnutella protocol, which it isn't currently. It's just a personal
      experiment that is being conducted, using the Shareaza users as
      beta testers. (the term "beta" being funny in this context, as it
      means also "idiot" in French).

      :2) Rename his protocol

      That goes without saying that Mike's Protocol (MP, like Adam said)
      is far more accurate than Gnutella 2.

      Mike, please, if you don't want to loose the remaining credit you have
      in this community, stop pretending your implementation of MP is what
      we want for Gnutella 2.

      I think we all want to make Gnutella evolve for the better, but whatever
      evolution we are doing, we are going to do it together, and not you
      against all of us. Stop pretending you have G2 and tell your beta
      testers that you are acutally implementing MP, not G2.

      It is true you are doing us all a major disservice. Forcing us to come
      up with G3 would not only weaken us all, it would also confuse our
      end-users and shed some discredit on our efforts.

      Yes, this is politics, but try to understand that noone owns the Gnutella
      protocol, and that it is alive only because we want it to be alive. Noone
      should embark in any of this just because we can do it.

      Any major vendor here could do the same as you did, and the resulting net
      effect would be total chaos and the death of Gnutella as we know it.
      We would have LimeNet, BearNet, GnucNet, ShareNet, SwapNet, and Gtk-GNet.
      All peacefully coexisting, until they die out of asphyxia. Perhaps then
      a new protocol would emerge on top of that mess, but it would mean a
      dead Gnutella. An extinct species.

      Don't think that because we make this plea, we are the weak ones and you
      have the power to change things. It is quite the contrary actually, but
      it is not clear to you yet.

    • Philippe Verdy
      This is standard behavior: pong messages collect IP addresses of foreign hosts, and are forwarded later to other hosts. Forwarding implies that the current
      Message 65 of 65 , Nov 24, 2002
        This is standard behavior: pong messages collect IP addresses of foreign
        hosts, and are forwarded later to other hosts. Forwarding implies that the
        current send of the IP datagram is not the initial sender of the pong
        Reread the basic description of the Gnutella protocol, you should alredy
        know that Gnutella heavily uses the concept of packet forwarding by
        application (forwarding is not performed at the IP level, given that pong
        messages are not intended to be used only by 1 client, but can be cached and
        sent to other clients as well).
        The same would be true for any other forwarded messages in the Gnutella

        The current Gnutella policy severely restricts the usage of packet

        Also, on TCP connections, there will nearly always be a lot of Gnutella
        packets coming from many different sources, which will never be the IP
        address of the currently connected host. Basically, most Gnutella clients
        have actual IP connections to very few hosts. Most packets need to be
        forwarded to create a web of much more accessible hosts.

        The only case where the IP address in a Gnutella message could match the IP
        address of the IP datagram (TCP or UDP) is when the packet has not been
        forwarded, i.e. when it contains informations directly attached to one of
        the very few servents to which your Gnutella servent is connected.

        Please study the Gnutella protocol before going further. It seems that you
        have not understood how P2P protocols work: this is NOT a client/server
        protocol based on central servers like on the traditional web!
        Visit the Files section of the Gnutella Developer Forum, and read the specs
        there (notably the rules regarding the TTL and Hops fields in Gnutella
        messages, and how they allow application-level forwarding)...

        ----- Original Message -----
        From: "prashthy" <pmurthy@...>
        To: <the_gdf@yahoogroups.com>
        Sent: Sunday, November 24, 2002 1:18 AM
        Subject: [the_gdf] IP Address in Sniffed Packet


        I tried using the ethereal analyzer (packet sniffer
        for windows) to view the packet headers for gnutella
        messages. I observed that the IP address in the
        payload of the pong messages received is different
        from the source IP address in the IP header. This
        seems to be the case for all gnutella pong messages
        that I sniffed on my machine. What could be the reason
        for this ?

        An example:

        Source IP address (from Ip header) :
        IP address in the pong message received:


        To unsubscribe from this group, send an email to:

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.