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

RE: [the_gdf] Searches on Gnutella2

Expand Messages
  • b8_bavard
    ... OK, I will go to shareaza forums for these questions. I still think it is a bad idea, as gnutella2, even if it does not share a lot with gnutella, still
    Message 1 of 10 , May 1 7:37 AM
      > If you are going to ask questions about "Gnutella2" you should likely do
      > that on the Shareaza forums. If you do it here, it could upset developers.
      > The Shareaza specific protocol is not the Gnutella protocol and it doesn't
      > have the support of most developers here on the GDF.

      OK, I will go to shareaza forums for these questions. I still think it
      is a bad idea, as gnutella2, even if it does not share a lot with
      gnutella, still shares some parts, such as the connection handshake
      and the download requests. Moreover, most gnutella2 clients (the two
      ones I know) are also gnutella clients. Anyway, I don't see the
      difference between shareaza, which is using a different but specified
      protocol when both clients are able to use it, and bearshare, which is
      using an unknown authentication scheme, several crypted messages, and
      priviledges its own peers as leaves and still calls itself a gnutella
      client.

      I don't want to upset/attack anybody by talking about shareaza, I only
      thought it was a TECHNICAL group about gnutella related stuff, and
      that such a TECHNICAL discussion could only help other developpers to
      better know gnutella2, and to understand the benefits of both
      protocols. Don't tell me gnutella2 is not related to gnutella, it is
      as related to gnutella as other vendor-specific extensions.

      - b8_bavard (mldonkey)
      --------------------------------------
      Homepage: http://www.mldonkey.net/
      --------------------------------------
    • Dave Nicponski
      [QUOTE] Anyway, I don t see the difference between shareaza, which is using a different but specified protocol when both clients are able to use it, and
      Message 2 of 10 , May 1 7:47 AM
        [QUOTE]
        Anyway, I don't see the
        difference between shareaza, which is using a different but specified
        protocol when both clients are able to use it, and bearshare, which is
        using an unknown authentication scheme, several crypted messages, and
        priviledges its own peers as leaves and still calls itself a gnutella
        client.
        [/QUOTE]

        Whether you see the difference or not doesn't matter.
        1) Auth scheme - used to prove identity as a BearShare client. That's all.
        2) Crypted messages - Such as? The vendor messages? I don't believe we are encrypting messages. Digitally signing to allow authentication of source and prevent alteration, in some cases, but not encrypting them.
        3) Priviledges its own peers as leaves - What does this mean? How can you justify this statement? You can't? Didn't think so. Keep your accusations on Shareaza forums, not here.

        [QUOTE]
        I don't want to upset/attack anybody by talking about shareaza, I only
        thought it was a TECHNICAL group about gnutella related stuff, and
        that such a TECHNICAL discussion could only help other developpers to
        better know gnutella2, and to understand the benefits of both
        protocols. Don't tell me gnutella2 is not related to gnutella, it is
        as related to gnutella as other vendor-specific extensions.
        [/QUOTE]

        Whether you want to be told that "Mike's Protocol" is not "Gnutella" or not also does not matter: The prevailing mentatilty in this group is that it is not related, and as such, is offtopic, and does not belong here any more than an end user's question (also maybe Gnutella related) does not belong here.

        -dave-
      • b8_bavard
        ... What is this information useful for ? You don t trust other gnutella clients ? What is the difference in behavior between trusted and untrusted clients ?
        Message 3 of 10 , May 1 8:02 AM
          > Whether you see the difference or not doesn't matter.
          > 1) Auth scheme - used to prove identity as a BearShare client. That's all.

          What is this information useful for ? You don't trust other
          gnutella clients ? What is the difference in behavior between
          trusted and untrusted clients ?

          > 2) Crypted messages - Such as? The vendor messages? I don't
          > 2) believe we are encrypting messages. Digitally signing to allow
          > 2) authentication of source and prevent alteration, in some cases,
          > 2) but not encrypting them.

          Just explain me the BEAR/3 message, then. How can I sign messages
          in my client so that a bearshare client accept them ? Where is the
          spec ?

          > 3) Priviledges its own peers as leaves - What does this mean? How
          > 3) can you justify this statement? You can't? Didn't think so.

          If you read previous mails, there are lots of discussions about the
          fact that bearshare mostly only takes bearshare leaves. In a
          previous mail, I asked why I could so easily connect to limewire
          ultrapeers and not bearshare ones (it was yesterday evening...).

          > 3) Keep your accusations on Shareaza forums, not here.

          Hehe, I never went there.

          > Whether you want to be told that "Mike's Protocol" is not
          > "Gnutella" or not also does not matter: The prevailing mentatilty
          > in this group is that it is not related, and as such, is offtopic,
          > and does not belong here any more than an end user's question (also
          > maybe Gnutella related) does not belong here.

          Who is deciding what can be said or not in this forum ? I don't like
          the Alt-Locs exchange in gnutella, too expensive, but I don't prevent
          anyone here from discussing about the fact that there should be a coma
          or not at some point in the Alt-Locs.

          What about BEAR/3 spec, now ?

          - b8_bavard (mldonkey)
          --------------------------------------
          Homepage: http://www.mldonkey.net/
          --------------------------------------
        • dague12
          The problems you are having there might be related to the query key. If you are performing a search from a firewalled leaf, a query key request (QKR) must be
          Message 4 of 10 , May 1 8:38 AM
            The problems you are having there might be related to the query key.
            If you are performing a search from a firewalled leaf, a query key
            request (QKR) must be requested first (through UDP to the remote hub)
            with the address of the local hub that you intend the query hits to
            go by. Then when the QKA acknowledgement comes back, in this case
            routed through the local hub, the Q2 query can be sent out to the
            remote hub (thorugh UDP), specifying the return address for the local
            hub, so that it can send the query hit back to you.

            dague12

            --- In the_gdf@yahoogroups.com, b8_bavard <mldonkey@m...> wrote:
            >
            > We have different problems with Gnutella2:
            >
            > 1. Searches on TCP never return any results (even UDP results). We
            > tried:
            > Q2 without UDP child (to get only TCP replies)
            > Q2 with UDP child containing address and no query key (seen on
            some traces with shareaza)
            > Q2 with UDP child containing address and query key 0 (some
            received queries from shareaza are like that)
            > Q2 with UDP child containing address and query key obtained by
            UDP
            >
            > None of these attempts worked.
            >
            > 2. Searches on UDP with two keywords does not work. Searches with
            one
            > keyword seem to work (our defragmentation algorithm is not yet
            > working, but we receive the corresponding fragmented packets).
            >
            > 3. Is there an updated draft of the protocol ? For example, the Q1
            > message does not appear in the current one (is it obsolete ?).
            > Some children packets have a different format from the one
            > specified (Q2.UDP in particular). It would also be interesting to
            > have more than the format of the messages, ie when to use them.
            > When should we send the LNI and KHL packets ? Shareaza sends
            them
            > several times on a connection, is it required ?
            >
            > - b8_bavard (mldonkey)
            > --------------------------------------
            > Homepage: http://www.mldonkey.net/
            > --------------------------------------
          • Dave Nicponski
            [QUOTE] What is this information useful for ? You don t trust other gnutella clients ? What is the difference in behavior between trusted and untrusted clients
            Message 5 of 10 , May 1 8:42 AM
              [QUOTE]
              What is this information useful for ? You don't trust other
              gnutella clients ? What is the difference in behavior between
              trusted and untrusted clients ?
              [/QUOTE]

              This allows BearShare clients with known behavior patterns to be verified, and assumptions of good or bad behavior made as a result.

              [QUOTE]
              Just explain me the BEAR/3 message, then. How can I sign messages
              in my client so that a bearshare client accept them ? Where is the
              spec ?
              [/QUOTE]

              Bear/3 is a part of the BearShare identification scheme. Again, this is not useful to non-BearShare clients.

              [QUOTE]
              If you read previous mails, there are lots of discussions about the
              fact that bearshare mostly only takes bearshare leaves. In a
              previous mail, I asked why I could so easily connect to limewire
              ultrapeers and not bearshare ones (it was yesterday evening...).
              [/QUOTE]

              Now that is simply not true, by any stretch. In fact, BearShare nodes are *forced* to accept non-BearShare leaves! So that is just BS (not BearShare!)

              [QUOTE]
              Who is deciding what can be said or not in this forum ? I don't like
              the Alt-Locs exchange in gnutella, too expensive, but I don't prevent
              anyone here from discussing about the fact that there should be a coma
              or not at some point in the Alt-Locs.
              [/QUOTE]

              This is a perfect example of the necessity for verifiable authentication of nodes. There are some good rules that would ensure propegation and validity of the majority of AltLocs. We hammered them all out, and posted them here. Not a single other vendor bothered to implement all of those common sense ideas, so far as I know. As a result, there is a massive (and growing) quality difference in AltLocs given by BearShare's and AltLocs given by other clients. BearShare behavior is known (to us) and therefore a Bear can make a quality assumption about an AltLoc from another Bear that it cannot from a non-bear. See? Now, BearShare will still give AltLocs to non-Bears, but it can "trust" those from Bear's as being recently verified (because we *know* that Bears follow smart rules, whereas noone else does for sure)

              [QUOTE]
              What about BEAR/3 spec, now ?
              [/QUOTE]

              Not usable by Non-BearShare nodes, see above.

              Let me say this once and for all, since I see this brought up here every so often...

              **************
              The Authentication feature is not something that will be useable by other vendors, nor does it make BearShare "proprietary" because of it. Indeed, it only establishes that a client claiming to be a BearShare really *IS* a BearShare, and not some hacked client with a "BearShare" user agent, (remember QTrax, with the "Limewire BearShare Gnucleus Xolox Shareaza" user agent??) It does not give an automatic "preference" to BearShare clients, nor does it adversly impact those who cannot authenticate.
              **************

              Now, let me ask you this:

              Why, oh why, are you so interested in BearShare authentication specs?
              For your own client?
              Your own NON-BEARSHARE client?
              Then you *shouldn't* be able to authenticate yourself, as you *aren't* a BearShare!!

              -dave-
            • Vinnie
              ... If you are referring to BEAR vendor messages with subselector 3, the answer is that it is a product identifier message. This message informs the other
              Message 6 of 10 , May 1 8:53 AM
                --- In the_gdf@yahoogroups.com, b8_bavard <mldonkey@m...> wrote:
                > Just explain me the BEAR/3 message, then.

                If you are referring to BEAR vendor messages with subselector 3, the
                answer is that it is a "product identifier" message. This message
                informs the other connection of its version number (currently 4.2.5)
                and track (alpha, beta, or release). The message is digitally signed,
                and used to "signal" product updates.

                > How can I sign messages
                > in my client so that a bearshare client accept them ?

                Other vendors cannot produce valid BEAR/3 messages, by necessity,
                since they are not BearShare servents. Feel free to report whatever
                you want in the User-Agent during connection handshake, however.
                Please note that BearShare may deny you a host connection if the
                word "BearShare" appears in the User-Agent and the authentication
                test fails. The solution is simply to change your User-Agent string
                to something that does not include the word "BearShare". It is
                trademarked, after all.

                > If you read previous mails, there are lots of discussions about
                the
                > fact that bearshare mostly only takes bearshare leaves. In a
                > previous mail, I asked why I could so easily connect to limewire
                > ultrapeers and not bearshare ones (it was yesterday evening...).

                BearShare versions earlier than 4.2.5 did not accept non-BearShare
                leaves. Versions 4.2.5 and later accept all types of leaves.
                Therefore, over time the problem you describe should disappear.
              Your message has been successfully submitted and would be delivered to recipients shortly.