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

Re: RAZA 1.8.10.8 must be stopped

Expand Messages
  • Vinnie
    ... RAZA ... Perhaps Shareaza nodes keeping hitting the cache until they find an MP (Mike s Protocol) host? If there are few MP hubs , or the web cache
    Message 1 of 22 , Apr 5, 2004
    • 0 Attachment
      --- In the_gdf@yahoogroups.com, Christian Biere <christianbiere@g...>
      wrote:
      > am I the only one who notices *very* frequent request rates from
      RAZA
      > 1.8.10.8?

      Perhaps Shareaza nodes keeping hitting the cache until they find an
      MP (Mike's Protocol) host? If there are few MP "hubs", or the web
      cache doesn't support requests for particular types of addresses, the
      clients might keep requesting over and over when there are connection
      problems.

      > I informed them resp. him several days ago but got no answer
      > whatsoever.

      I don't think Shareaza is being actively developed any more. Users
      are complaining in the forum and there hasn't been a release in ages.

      This is a perfect example of too many chefs spoiling the broth. Had
      Mike concentrated on a single protocol instead of 4(?) this problem
      wouldn't exist.
    • Philippe Verdy
      From: Christian Biere ... This problem can be explained: Shareaza has a builtin support for what it calls Gnutella1 but it can t even
      Message 2 of 22 , Apr 5, 2004
      • 0 Attachment
        From: "Christian Biere" <christianbiere@...>
        > am I the only one who notices *very* frequent request rates from RAZA
        > 1.8.10.8? I informed them resp. him several days ago but got no answer
        > whatsoever.
        > If you look at public available GWC stats you can see that RAZA 1.8.10.8
        > is in the top 10 of (almost) all caches. Also, RAZA has been out for a while
        > already my request rates have suddenly doubled(!) overnight.
        > Or have a look at "http://jason.ionichost.com/". RAZA is listed with over
        > 30000(!) requests per hour. Although, Gnutella2 is OT here, GWCs are
        > shared between both so you might care.

        This problem can be explained: Shareaza has a builtin support for what it calls
        Gnutella1 but it can't even connect to any other legitimate Gnutella servent
        because of too many errors in its implementation. So if a user enables the very
        bad implementation of the infamous "Gnutella1" protocol in Shareaza (which is
        NOT our Gnutella protocol), it will constantly harness any Gwebcache because all
        its attempts will fail.

        Shamely, Shareaza has not included any feature to stop attempts to connect to
        Gnutella1 if more than 200 connections failed. If the Shareaza user is not
        looking at it scrupulously, Shareaza will consume tens of thousands of
        connection attempts to Gnutella. This is also a side effect of the attempt to
        ban completely Shareaza to connect to many servents.

        Because Mike has stopped working seriously on its Gnutella implementation, the
        Gnutella1 protocol it supports is now a damaging antiquity. If Mike can't
        support Gnutella with the same level of quality as its prefered MP protocol that
        he names "Gnutella2", he should resign and no more attempt to use the Gnutella
        network with its Gnutella1 protocol.

        I do think that Mike should dismiss its "Gnutella1" protocol from Shareaza, and
        consider working only in its own network, until he finds time to debug his
        "gnutella1" implementation which is not "Gnutella" (it still only works with
        some old versions of Gnutella servents, however quite unreliably). Keeping this
        outdated implementation in Shareaza is not worth the efforts even for his
        users...

        Mike has now all what he needs to run Shareaza in its own realm with his MP
        protocol and the support of GWebCache 2 for alternate networks. I do think that
        open-sourced multiprotocol servents, other than Shareaza, perform a better
        gateway between MP and Gnutella networks... MLdonkey is not as much abusive as
        Shareaza, but it has its own problems too with its interpretation of the QRP
        mechanism; today I would better trust the MLdonkey author to create a safe
        gateway between both networks, than Mike in Shareaza: Mike cannot simply support
        alone both its protocol, its own servent, its own network, and the true Gnutella
        network.
      • Nilton Braga
        Hello. I`m applying to my master thesis now. I intend to study p2p networks, using gnutella as a base protocol. The fact is: all papers refer to gnutella as
        Message 3 of 22 , Apr 5, 2004
        • 0 Attachment
          Hello.

          I`m applying to my master thesis now.

          I intend to study p2p networks, using gnutella as a
          base protocol.

          The fact is: all papers refer to gnutella as being a
          broadcast-all-nodes network, but I read at
          http://rfc-gnutella.sourceforge.net/developer/index.html
          that this new version (0.6) is not solely
          broadcast-based and, instead, has introduced the
          concept of Ultrapeer in the gnutella network.

          Question: the vast majority of gnutella clients,
          today, run which version? V 0.4 or V 0.6?

          Thank you in advance. I need to know in which version
          I'll base my thesis, v0.4 or v0.6.

          --Nilton Braga


          ______________________________________________________________________

          Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
          http://br.yahoo.com/info/mail.html
        • Greg Bildson
          Everything is V 0.6. Further, the majority of clients implement dynamic querying which is not broadcast. Instead, dynamic querying selectively forwards
          Message 4 of 22 , Apr 5, 2004
          • 0 Attachment
            Everything is V 0.6. Further, the majority of clients implement dynamic
            querying which is not broadcast. Instead, dynamic querying selectively
            forwards queries from the first ultrapeer down other connections and adjusts
            the TTL of the query in order to achieve a specific number of results. This
            vastly reduces the overhead of dynamic queries versus broadcast queries.

            Thanks
            -greg
            -----Original Message-----
            From: Nilton Braga [mailto:ncbgroups@...]
            Sent: Monday, April 05, 2004 5:38 PM
            To: the_gdf@yahoogroups.com
            Subject: [the_gdf] v 0.4 or 0.6?


            Hello.

            I`m applying to my master thesis now.

            I intend to study p2p networks, using gnutella as a
            base protocol.

            The fact is: all papers refer to gnutella as being a
            broadcast-all-nodes network, but I read at
            http://rfc-gnutella.sourceforge.net/developer/index.html
            that this new version (0.6) is not solely
            broadcast-based and, instead, has introduced the
            concept of Ultrapeer in the gnutella network.

            Question: the vast majority of gnutella clients,
            today, run which version? V 0.4 or V 0.6?

            Thank you in advance. I need to know in which version
            I'll base my thesis, v0.4 or v0.6.

            --Nilton Braga


            ______________________________________________________________________

            Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
            http://br.yahoo.com/info/mail.html



            ----------------------------------------------------------------------------
            --
            Yahoo! Groups Links

            a.. To visit your group on the web, go to:
            http://groups.yahoo.com/group/the_gdf/

            b.. To unsubscribe from this group, send an email to:
            the_gdf-unsubscribe@yahoogroups.com

            c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



            [Non-text portions of this message have been removed]
          • gregorio.roper@t-online.de
            The vast majority of clients run version 0.6. Most of them even support further extensions to the protocol that you will find in the files section of this
            Message 5 of 22 , Apr 5, 2004
            • 0 Attachment
              The vast majority of clients run version 0.6. Most of them even support further extensions
              to the protocol that you will find in the files section of this Yahoo Group:
              http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/

              Especially the dynamic querying proposal (and related proposals), which are supported by
              LimeWire and BearShare at least, have had a large impact on the network topology.

              LimeWire and Swapper (?) also support out-of-band delivery of query results (via UDP).

              mfg
              gregorio

              Nilton Braga wrote:
              > Hello.
              >
              > I`m applying to my master thesis now.
              >
              > I intend to study p2p networks, using gnutella as a
              > base protocol.
              >
              > The fact is: all papers refer to gnutella as being a
              > broadcast-all-nodes network, but I read at
              > http://rfc-gnutella.sourceforge.net/developer/index.html
              > that this new version (0.6) is not solely
              > broadcast-based and, instead, has introduced the
              > concept of Ultrapeer in the gnutella network.
              >
              > Question: the vast majority of gnutella clients,
              > today, run which version? V 0.4 or V 0.6?
              >
              > Thank you in advance. I need to know in which version
              > I'll base my thesis, v0.4 or v0.6.
              >
              > --Nilton Braga
              >
              >
              > ______________________________________________________________________
              >
              > Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
              > http://br.yahoo.com/info/mail.html
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
            • gregorio.roper@t-online.de
              ... Even worse, he stopped working seriously on his client at all, which doesn t stop people from using it... ... It would already help if he would stop
              Message 6 of 22 , Apr 5, 2004
              • 0 Attachment
                Philippe Verdy wrote:

                > Because Mike has stopped working seriously on its Gnutella implementation, the
                > Gnutella1 protocol it supports is now a damaging antiquity. If Mike can't
                > support Gnutella with the same level of quality as its prefered MP protocol that
                > he names "Gnutella2", he should resign and no more attempt to use the Gnutella
                > network with its Gnutella1 protocol.

                Even worse, he stopped working seriously on his client at all, which doesn't stop people
                from using it...

                > I do think that Mike should dismiss its "Gnutella1" protocol from Shareaza, and
                > consider working only in its own network, until he finds time to debug his
                > "gnutella1" implementation which is not "Gnutella" (it still only works with
                > some old versions of Gnutella servents, however quite unreliably). Keeping this
                > outdated implementation in Shareaza is not worth the efforts even for his
                > users...

                It would already help if he would stop Shareaza from sending 1KB webpages along with its
                503s...

                > Mike has now all what he needs to run Shareaza in its own realm with his MP
                > protocol and the support of GWebCache 2 for alternate networks. I do think that
                > open-sourced multiprotocol servents, other than Shareaza, perform a better
                > gateway between MP and Gnutella networks... MLdonkey is not as much abusive as
                > Shareaza, but it has its own problems too with its interpretation of the QRP
                > mechanism; today I would better trust the MLdonkey author to create a safe
                > gateway between both networks, than Mike in Shareaza: Mike cannot simply support
                > alone both its protocol, its own servent, its own network, and the true Gnutella
                > network.

                Neither MLdonkey's nor Shareaza's Gnutella support is up-to-date. And I don't want a
                gateway. Clients connecting to multiple p2p-networks suck unless those p2p networks serve
                radically different purposes.

                mfg
                gregorio
              • Philippe Verdy
                In fact the 0.6 protocol is not a change in the topology used in Gnutella. The version number was introduced because it uses another N-way handhaking mechanism
                Message 7 of 22 , Apr 5, 2004
                • 0 Attachment
                  In fact the 0.6 protocol is not a change in the topology used in Gnutella. The
                  version number was introduced because it uses another N-way handhaking mechanism
                  which makes it behave like HTTP. This is the reason why nearly all servents
                  today will use only the 0.6 handshaling mechanism which is now mostly required
                  to connect to Gnutella servents.

                  The topological change was introduced a couple of years ago by Limewire in its
                  UltraPeer proposal (which requires first the use of the 0.6 handshakes also
                  introduced nearly at the same time by LimeWire). Today, a vast majority of
                  servents understand the UltraPeer protocol, which is an application of the QRP
                  extension (whose version is also negociated with the 0.6 hadnshakes).

                  So, you can't build any serious servent today that will connect to other
                  Gnutella nodes without implementing what is considered now part of the core of
                  the informal "0.6" Gnutella protocol, which groups almost all extensions which
                  were implemented in LimeWire. Note that other servents have since refined their
                  own use of these extensions, without compromizing too much the interoperability.
                  BearShare, GTKG and Swapper.Net have these basic features required today, and
                  that have finally been integrated, after long discussions, first in a revized
                  0.4 specification (in fact it was version 0.56 in its last revizion by the
                  original maintainer) which added some compatibility notes.

                  Then the 0.6 draft has emerged (it is still not completely finished but will be
                  soon, as we get more experience to merge the different experiences into an
                  agreed interoperable solution. The 0.6 protocol would not have been so long if
                  there had not been so much urgent need to create extensions to the 0.56 protocol
                  published by Clip2 (now dead). Each vendor first needed to keep a compatibility
                  with their legacy installed base, and also experiment with these extensions.

                  So the first extensions which were created, that were not documented by Clip2,
                  or badly documented in their experimental phase were disagreeing on the format
                  of these extensions. But the most important pressures have been is estabilishing
                  usage policies and keeping the statistics on high scrutiny. This was needed
                  because Gnutella had reached previously a critical point where it would have
                  completely collapsed if nothing had been done.

                  So if you study only the 0.4 protocol, you are missing almost all the important
                  policies which were discussed here and are still maintained, and that allows the
                  protocol to work. Several topologies have been studied, but Gnutella has in fact
                  been improved most often by local implementation designs that apply and check
                  policies silentely in the networking core; most of these changes do not
                  necessarily require a change in the protocol (notably for the topological
                  model).

                  However today, nobody would work well without UltraPeers and Leaves. All
                  servents today must understand and implement and use the 0.6 handshaking, and
                  the 0.4 handshakes (as indicated in the 0.56 PDF spec by Clip2) are completely
                  obsolete and most often rejected. We depend too much today on the capability of
                  performing HTTP-like n-way handshakes, which allows several things:

                  - allowing to use the same port for both HTP and GNUTELLA (the 0.6 handhake is
                  recognized by the "GNUTELLA" verb as a special extension of HTTP); beside
                  handhakes, the content-body is not, however, compliant with HTTP and is specific
                  to Gnutella messaging.
                  - indicating acceptance of the UltraPeer protocol
                  - negociating extensions support and versions
                  - indicating if running as a Shielded leaf or UltraPeer or Peer
                  - supporting signature and authentication mechanisms
                  - providing alternate hosts, notably for rejected connections (no more slot
                  available)

                  The 0.6 draft contains further documentation details needed for interoperability
                  of extensions. Notably the GGEP extension mechanism is now the only one used for
                  all newer message extensions, and the GEM encoding has been retained only for
                  very few legacy extensions that work well without GGEP.

                  Today I would say that Gnutella is not fully implementing the 0.6 draft, which
                  is more a like a convergence goal. The 0.4 protocol, plus a few "working
                  proposals" like UltraPeers, QRP, GGEP, HUGE, Gwebcache for bootstrap discovery,
                  are what is needed to build any working Gnutella servent today. There are other
                  extensions which are interoperable but shose support is still not mandatory.
                  The most important thing is the use of bandwidth policy control in all good
                  servents.

                  Those minor servents that attempted to abuse the network have killed themselves,
                  because they could not scale thir own installations to more than a few
                  thousands. You may think that writing a Gnutella servent is simple, but today,
                  good servents are written with about 250,000 to 500,000 lines of source code
                  (with about 100,000 lines for the networking core protocol itself and its
                  extensions, the rest in the GUI).

                  This level explains why it is nearly impossible for a single author to write and
                  support more than one protocol (and why the "Gnutella2" proposal made by Mike
                  alone was rejected, because it was not necessary and implied rewriting and
                  supporting most of the 100,000 lines of code needed to support the protocol, for
                  no significant benefit).

                  Today Gnutella evolves gradually through various experimentations, and many
                  great improvements can be made under the surface without needing a rewrite of
                  the core protocol itself. This includes internal implementation changes to
                  create better topologies.

                  If one had to rewrite a full core alone, it would take about 1 year of full-time
                  work, or 4 months with a small team with 2 or 3 core programmers. The other
                  part, with the GUI, would also require about one half year alone, or a few
                  months with a design team. The development time however is not inversely
                  proportional to the number of programmers, because they also need to discuss
                  together and coordinate their works with common specifications. Experience
                  prooves that specifying and documenting a project is much harder than writing
                  it, as this is a collaborative task.

                  Mike was able to develop alone his own version of the protocol, with its own
                  caveats, just because he did not feel he needed to document it. Choices were
                  made arbitrarily based on his past experience, but ignoring other problems that
                  were experimented by others, and that are still common between Mike's protocol
                  and Gnutella.

                  Basically, there's nothing very new in MP face to Gnutella, as it just rewrites
                  things which were discussed here; Mike did not want to bother discussing them
                  and wanted to write code immediately. Now he faces alone the problem of
                  maintaining his protocol in sync with Gnutella, and it will be hard for Mike to
                  make it open to other servent vendors, without creating new interoperability
                  problems.

                  The initial mission of Gnutella is to be a open platform, which means here
                  interoperable under some policies and open specifications, placed in the public
                  domain or under a royaltee-free open-sourced licence. When contributors accept
                  this, they can create their own experimentations and exclusive features without
                  harming the network, but they instead improve it by adding mode nodes, more
                  reachable contents and globally faster and more efficient networking.

                  If you want to study Gnutella, it's important to speak about the protocol as a
                  dynamic platform which is not fully described in a single specification. The
                  Internet itself is born from such collaborative works and is, by essence, also a
                  peer-to-peer network since it was opened to other networks than DARPA, and
                  placed under the authority of IETF.

                  However, unlike IETF, Gnutella has no formal existence and no administration
                  costs. Each one endorses these costs himself. The control of Gnutella is
                  collaborative (peer-to-peer) rather than centralized under a single central
                  authority. The GDF is then an informal working group which wants to acheive the
                  same galls as the hierachic organization headed by IETF for Internet, except
                  that it has no chief, no chairman, no single press relation chief, no required
                  costs to connect to it; anyone can then participate equally, even if Gnutella is
                  dominated by a few commercial distributors that can dedicate and pay a permanent
                  support team.

                  ----- Original Message -----
                  From: "Nilton Braga" <ncbgroups@...>
                  To: <the_gdf@yahoogroups.com>
                  Sent: Monday, April 05, 2004 11:37 PM
                  Subject: [the_gdf] v 0.4 or 0.6?


                  > Hello.
                  >
                  > I`m applying to my master thesis now.
                  >
                  > I intend to study p2p networks, using gnutella as a
                  > base protocol.
                  >
                  > The fact is: all papers refer to gnutella as being a
                  > broadcast-all-nodes network, but I read at
                  > http://rfc-gnutella.sourceforge.net/developer/index.html
                  > that this new version (0.6) is not solely
                  > broadcast-based and, instead, has introduced the
                  > concept of Ultrapeer in the gnutella network.
                  >
                  > Question: the vast majority of gnutella clients,
                  > today, run which version? V 0.4 or V 0.6?
                  >
                  > Thank you in advance. I need to know in which version
                  > I'll base my thesis, v0.4 or v0.6.
                  >
                  > --Nilton Braga
                  >
                  >
                  > ______________________________________________________________________
                  >
                  > Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
                  > http://br.yahoo.com/info/mail.html
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                • Philippe Verdy
                  From: ... further extensions ... supported by ... topology. ... (via UDP). Thanks for pointing these very important additions to
                  Message 8 of 22 , Apr 5, 2004
                  • 0 Attachment
                    From: <gregorio.roper@...>
                    > The vast majority of clients run version 0.6. Most of them even support
                    further extensions
                    > to the protocol that you will find in the files section of this Yahoo Group:
                    > http://groups.yahoo.com/group/the_gdf/files/Proposals/Working%20Proposals/
                    >
                    > Especially the dynamic querying proposal (and related proposals), which are
                    supported by
                    > LimeWire and BearShare at least, have had a large impact on the network
                    topology.
                    >
                    > LimeWire and Swapper (?) also support out-of-band delivery of query results
                    (via UDP).

                    Thanks for pointing these very important additions to the protocol, which have a
                    big impact on the effective search topology. However they are still not part of
                    the 0.6 draft, even if they are now widely deployed in very common servents.
                    Mostly because other servents are testing their own extensions too to address
                    some similar problems, and have decided to test them first before trying to
                    integrate dynamic querying and GUESS/UDP into their servents.

                    These two extensions are more in the spirit of Peer-to-Peer because they work by
                    bypassing the hierarchical model added by UltraPeers.

                    Another missing addition which LimeWire has added is the inter-ultrapeer QRP
                    exchange. This was intended in the initial design of QRP, but implemented only
                    on the last hop between the leaf and the UltraPeer, so the original broadcast
                    model was still used between UltraPeers. If you remove all Leaf nodes, the
                    network of UltraPeers still forms a legacy Gnutella network, with the same
                    limits as the legacy 0.4 broadcast model, except that the hierarchization
                    selects the best performing nodes which have more equal capabilities than in the
                    old model where modem users were considered equal to broadband users.

                    But as today, there's a big increase of broadband users (connections with more
                    than 1 megabit/s are exploding) so the justification of UltraPeers is being
                    eroded as broadband users will tend to have mostly permanent connections
                    requiring the use of firewalls, which means that in fact we have more
                    difficulties to find good UltraPeers than before, when many leaf-only nodes are
                    now broadband users, that can apply a higher stress on the remaining UltraPeers.

                    Bypassing the cloud of UltraPeers is a necessity today, and GUESS/UDP as well as
                    inter-UltraPeer QRP exchange really helps reducing the stress on UltraPeers
                    performance (a "idle" broadband LimeWire UltraPeer, that does not download or
                    uploads files, can support easily 30 leaf nodes with a traffic below 5kbit/s,
                    and that's a significant step to help convince users to let their servent run in
                    UltraPeer mode).

                    Probably the next immediate step will be to implement (independantly of the
                    Gnutella protocol itself) the UPNP support on Windows servents (needed if one
                    wants to perform well through Microsoft ICS, built into Windows XP and that will
                    soon be enabled by default in the next service pack published this summer), or
                    to help more efficiently users to configure their firewalls so that they can
                    accept incoming connections (pushed transfers are adding to the stress of
                    UltraPeers through which firewalled leaf nodes are connected).
                  • Philippe Verdy
                    From: ... want a ... networks serve ... By gateway I don t mean a way to forward queries from one network to another. Just the
                    Message 9 of 22 , Apr 5, 2004
                    • 0 Attachment
                      From: <gregorio.roper@...>
                      > Neither MLdonkey's nor Shareaza's Gnutella support is up-to-date. And I don't
                      want a
                      > gateway. Clients connecting to multiple p2p-networks suck unless those p2p
                      networks serve
                      > radically different purposes.

                      By "gateway" I don't mean a way to forward queries from one network to another.
                      Just the possibility integrated in one servent to implement several separate
                      protocols, as if there was two distinct servents sharing the same files on the
                      same host.

                      This is enough to allow files to go through several networks (Gnutella, MP,
                      edk2, DirectConnect, Kazaa, and even OpenNap...), and probably better than
                      forcing users to run two separate servents, or stopping one in order to run a
                      second one to perform another search, because the integration can save lots of
                      host resources (notably in its single GUI interface implementation, and in some
                      common support libraries):

                      A user downloads a file from one network, which gets stored in a directory
                      shared on both networks. So files can be distributed and loaded equally on
                      either network.

                      This is not different from the situation where two hosts on the same LAN are
                      running distinct servents for distinct networks, but are sharing the same
                      internet access connection. There are ways to write a servent that will work
                      correctly in that situation without harming other hosts needing their own
                      bandwidth part on the shared internet bandwidth.

                      If we can admit that people will want to run multiple hosts on a LAN with
                      distinct servents, using a shared NAPT router to the internet, then we can
                      accept the fact that these hosts be merged into a single servent performing the
                      equivalent but locally without the NAPT device...
                    • Greg Bildson
                      Here, here. I agree with what Gregorio and Vinnie have said. It s time for Shareaza users to give the newest versions of dynamic querying clients a try. I
                      Message 10 of 22 , Apr 5, 2004
                      • 0 Attachment
                        Here, here. I agree with what Gregorio and Vinnie have said. It's time for Shareaza users to give the newest versions of dynamic querying clients a try. I think that they will find them to have the best of all features in clients like LimeWire and BearShare.

                        Shareaza and MLDonkey look problematic. Morpheus is problematic unless (or until) they improve their support for dynamic querying. This is really getting to the point of the old Gnutella 0.56 client that we had to actively get taken down from listing sites around the web for the ongoing health of the network. We have just recently found a problem with Morpheus' partial file sharing where they reject a download request, suggest a new range that they have available and then reject that request and suggest yet another range that they have available - repeat ad infinitum.

                        Thanks
                        -greg

                        ---------- Original Message ----------------------------------
                        From: "Vinnie" <vinnie@...>
                        --- In the_gdf@yahoogroups.com, Christian Biere <christianbiere@g...>
                        wrote:
                        > am I the only one who notices *very* frequent request rates from
                        RAZA
                        > 1.8.10.8?

                        Perhaps Shareaza nodes keeping hitting the cache until they find an
                        MP (Mike's Protocol) host? If there are few MP "hubs", or the web
                        cache doesn't support requests for particular types of addresses, the
                        clients might keep requesting over and over when there are connection
                        problems.

                        > I informed them resp. him several days ago but got no answer
                        > whatsoever.

                        I don't think Shareaza is being actively developed any more. Users
                        are complaining in the forum and there hasn't been a release in ages.

                        This is a perfect example of too many chefs spoiling the broth. Had
                        Mike concentrated on a single protocol instead of 4(?) this problem
                        wouldn't exist.
                      • Vinnie
                        ... supported by ... network topology. It is very apparent that dynamic querying represents one of the most significant improvements in the performance of the
                        Message 11 of 22 , Apr 5, 2004
                        • 0 Attachment
                          --- In the_gdf@yahoogroups.com, gregorio.roper@t... wrote:
                          > the dynamic querying proposal (and related proposals), which are
                          supported by
                          > LimeWire and BearShare at least, have had a large impact on the
                          network topology.

                          It is very apparent that dynamic querying represents one of the most
                          significant improvements in the performance of the Gnutella network.
                        • Vinnie
                          ... I would like to point out that some informal tests (where BearShare was disconnected from the main Gnutella segment) suggest that access to different
                          Message 12 of 22 , Apr 5, 2004
                          • 0 Attachment
                            --- In the_gdf@yahoogroups.com, "Greg Bildson" <gbildson@l...> wrote:
                            > Shareaza and MLDonkey look problematic.

                            I would like to point out that some informal tests (where BearShare
                            was disconnected from the "main" Gnutella segment) suggest that
                            access to different networks can increase the variety of content.
                          • Christian Biere
                            ... Yes, that s probably the case. However, this shows that Shareaza has a very bad back-off strategy - if any. I d think that using the same methods which are
                            Message 13 of 22 , Apr 6, 2004
                            • 0 Attachment
                              gregorio.roper@... wrote:
                              > The problem may be that there are more Shareaza users trying to connect
                              > to Gnutella than there are Ultrapeers accepting Shareaza leafs. Shareaza
                              > doesn't seem to keep only a small internal list of ultrapeers to connect
                              > to so it will soon fall back to the GWebCache system.

                              Yes, that's probably the case. However, this shows that Shareaza has a
                              very bad back-off strategy - if any. I'd think that using the same
                              methods which are used to prevent congestion with UDP-based protocols
                              should help (e.g., increasing delays between retries).

                              > Maybe closing the connection whenever you detect a harmful Shareaza
                              > version will save you some bandwidth.

                              In the short run maybe. In the long run they might come back over and over
                              again. And as always with Gnutella: "Think global!". If most GWCs would
                              reject a certain vendor, those that didn't would get hammered away. I've
                              changed my GWC now so that it returns *only* RAZA peers for RAZA and no
                              RAZA for any other vendor. Since RAZA (usually) sends a "net=gnutella2"
                              request, this should be the requested and expected behaviour (although
                              my GWC doesn't support the "net" parameter).

                              > Just looked through some of the GWebCaches, Shareaza requests really
                              > sky-rocketed during the last few days. That's pretty serious.

                              To me it also looked as if they moved like a herd from one GWC to another,
                              since these high rates come and go.

                              --
                              Christian
                            • Greg Bildson
                              Sure. We ve done those tests as well. However, that is no excuse for having flaky Gnutella support. All too often in the past, Gnutella has been the dumping
                              Message 14 of 22 , Apr 6, 2004
                              • 0 Attachment
                                Sure. We've done those tests as well. However, that is no excuse for
                                having flaky Gnutella support. All too often in the past, Gnutella has been
                                the dumping ground for clients that want to access the network in an overly
                                aggressive fashion. We've lived with various abuses to the network in the
                                past prior to finding a way to remove the problem. I'm sure we would all
                                prefer to avoid as much future abuse as possible.

                                Thanks
                                -greg
                                -----Original Message-----
                                From: Vinnie [mailto:vinnie@...]
                                Sent: Tuesday, April 06, 2004 1:03 AM
                                To: the_gdf@yahoogroups.com
                                Subject: [the_gdf] Re: RAZA 1.8.10.8 must be stopped


                                --- In the_gdf@yahoogroups.com, "Greg Bildson" <gbildson@l...> wrote:
                                > Shareaza and MLDonkey look problematic.

                                I would like to point out that some informal tests (where BearShare
                                was disconnected from the "main" Gnutella segment) suggest that
                                access to different networks can increase the variety of content.




                                ----------------------------------------------------------------------------
                                --
                                Yahoo! Groups Links

                                a.. To visit your group on the web, go to:
                                http://groups.yahoo.com/group/the_gdf/

                                b.. To unsubscribe from this group, send an email to:
                                the_gdf-unsubscribe@yahoogroups.com

                                c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



                                [Non-text portions of this message have been removed]
                              • Dave Nicponski
                                +1 to that! Lets nip it in the bud. -dave- [Quote] [...] However, that is no excuse for having flaky Gnutella support. All too often in the past, Gnutella has
                                Message 15 of 22 , Apr 6, 2004
                                • 0 Attachment
                                  +1 to that!

                                  Lets nip it in the bud.

                                  -dave-


                                  [Quote]
                                  [...] However, that is no excuse for having flaky Gnutella support. All too
                                  often
                                  in the past, Gnutella has been the dumping ground for clients that want to
                                  access
                                  the network in an overly aggressive fashion.
                                  [/Quote]
                                • Jann Röder
                                  We at Shareaza are aware of the problem, however we don t know what s causing it, though. Maybe something with Daylight saving time, that is unlikely though.
                                  Message 16 of 22 , Apr 6, 2004
                                  • 0 Attachment
                                    We at Shareaza are aware of the problem, however we don't know what's
                                    causing it, though. Maybe something with Daylight saving time, that is
                                    unlikely though. Shareaza 1.8.10.8 has been around for quite a while now
                                    and these GWC problems have only appeared just recently. I can asure you
                                    that Shareaza still is under active development. We are currently
                                    investigating this problem.

                                    Jann
                                  • Vinnie
                                    ... We?? Maybe this problem will disappear magically in the same manner it was brought about.
                                    Message 17 of 22 , Apr 6, 2004
                                    • 0 Attachment
                                      --- In the_gdf@yahoogroups.com, Jann Röder <jann_roeder@y...> wrote:
                                      > We at Shareaza

                                      We??

                                      Maybe this problem will disappear magically in the same manner it was
                                      brought about.
                                    • Philippe Verdy
                                      From: Vinnie ... Let s hope that this plural indicates that Mike has hired some developers to maintain its servent and reactivate its
                                      Message 18 of 22 , Apr 7, 2004
                                      • 0 Attachment
                                        From: "Vinnie" <vinnie@...>
                                        > Jann Röder <jann_roeder@y...> wrote:
                                        > > We at Shareaza
                                        > We??

                                        Let's hope that this plural indicates that Mike has hired some developers to
                                        maintain its servent and reactivate its development in the Gnutella branch. But
                                        I should suggest to Shareaza to stop forwarding searches from one network to the
                                        other. If Shareaza becomes a servent behaving like two completely separate
                                        implements (one for MP one for Gnutella) then it will regain its trust.

                                        There's actually no need to extend a search initiated in the MP network to the
                                        Gnutella network (and the reverse is true).

                                        What is possible is to share files on both networks or to initiate searches in
                                        parallel on two networks. Shareaza "Hubs" must not accept a MP search from its
                                        MP leaves and reroute them on Gnutella. If needed, a Shareaza leaf can initiate
                                        two connections to a MP Hub and a Gnutella UltraPeer...

                                        So it will ease the development and separate debugging of each protocol in their
                                        own isolated realm... The only connection will be made in the GUI and in the set
                                        of local shared files...
                                      • Philippe Verdy
                                        From: Christian Biere ... Not sure about that. RAZA skyrocketed in almost all working GWC servers. It s probably that we should apply
                                        Message 19 of 22 , Apr 7, 2004
                                        • 0 Attachment
                                          From: "Christian Biere" <christianbiere@...>
                                          > > Just looked through some of the GWebCaches, Shareaza requests really
                                          > > sky-rocketed during the last few days. That's pretty serious.
                                          >
                                          > To me it also looked as if they moved like a herd from one GWC to another,
                                          > since these high rates come and go.

                                          Not sure about that. RAZA skyrocketed in almost all working GWC servers.

                                          It's probably that we should apply an isolation mechanism so that GWC servers
                                          will only return RAZA to RAZA and no RAZA to others. This will work well for the
                                          medium term as well, as we will in fact help, rather than reject, RAZA to get
                                          its own connections in its own network, instead of letting it hammering too many
                                          hosts...

                                          If GWebcaches are all isolating RAZA nodes, then all bootstraps from RAZA will
                                          only find RAZA nodes, and progressively, it will be completely disconnected from
                                          the rest of the Gnet, because they won't find other Gnutella hosts once
                                          connected only to RAZA nodes. And Shareaza will need another way to find
                                          Gnutella hosts to conect to (let's hope it will not abuse us by forging its own
                                          identity in its GWC requests...)

                                          This is clearly a problem for my GWC too...
                                        • Philippe Verdy
                                          From: no_dammage ... Is that worth the development? I think that RAZA could be isolated permanently at least with a version check that
                                          Message 20 of 22 , Apr 7, 2004
                                          • 0 Attachment
                                            From: "no_dammage" <diman2001@...>
                                            > --- In the_gdf@yahoogroups.com, "Philippe Verdy" <verdy_p@w...> wrote:
                                            > > From: "Christian Biere" <christianbiere@g...>
                                            > > > > Just looked through some of the GWebCaches, Shareaza requests really
                                            > > > > sky-rocketed during the last few days. That's pretty serious.
                                            > > >
                                            > > > To me it also looked as if they moved like a herd from one GWC to
                                            > another,
                                            > > > since these high rates come and go.
                                            > >
                                            > > Not sure about that. RAZA skyrocketed in almost all working GWC servers.
                                            > >
                                            > > It's probably that we should apply an isolation mechanism so that
                                            > GWC servers
                                            > > will only return RAZA to RAZA and no RAZA to others. This will work
                                            > well for the
                                            > > medium term as well, as we will in fact help, rather than reject,
                                            > RAZA to get
                                            > > its own connections in its own network, instead of letting it
                                            > hammering too many
                                            > > hosts...
                                            > >
                                            > > If GWebcaches are all isolating RAZA nodes, then all bootstraps from
                                            > RAZA will
                                            > > only find RAZA nodes, and progressively, it will be completely
                                            > disconnected from
                                            > > the rest of the Gnet, because they won't find other Gnutella hosts once
                                            > > connected only to RAZA nodes. And Shareaza will need another way to find
                                            > > Gnutella hosts to conect to (let's hope it will not abuse us by
                                            > forging its own
                                            > > identity in its GWC requests...)
                                            > >
                                            > > This is clearly a problem for my GWC too...
                                            >
                                            > I have an idea: maybe create a new version of GWC, where such a
                                            > function is time-controlled? (two weeks) After this period the GWC
                                            > asks a central [neutral] server about the state and if RAZAOk ==
                                            > false, then wait another two weeks...Then, if this authority gives an
                                            > OK to add raza again to GNet, in the period of two weeks the GWCs will
                                            > allow connections again.
                                            > Important: this authority is 100% neutral (not developers, not users -
                                            > an authority) since the developers have their subjective and the users
                                            > their subjective opinions. Agree that if such an authority would
                                            > become a developer here, i won't call the name, raza won't enter Gnet
                                            > again and if a user, loving raza will become such a person, he will
                                            > let raza run all the time...

                                            Is that worth the development? I think that RAZA could be isolated permanently
                                            at least with a version check that excludes all versions 1.8*. Then RAZA can be
                                            updated and in a later release tested again to see if it complies with common
                                            rules.

                                            But a safer way would be that GWebcaches return preferably hosts with the same
                                            servent vendor ID with fewer hosts from other vendors (for example if a GWC
                                            returns 30 hosts, the first 5 could be hosts from that vendor, if we have it,
                                            then the other would be a random selection from all hosts, including the same
                                            vendor itself).

                                            No need to implement really GWC v2, as GWC v1 already has the options to allow
                                            such implementation, with the client=XXXX query parameter. (Most GWC servers now
                                            reject servents that don't give these client=XXXX and version=xyz parameters,
                                            and they even log them, so why not using this information in GWC v1?)

                                            It's just a way to allow aggregating servents from the same vendors, but still
                                            keep the interconnection open. Smaller vendors will then still be allowed to
                                            connect even if they don't find immediately any host with their own vendor ID
                                            (they can find them later using pongs and query hits).
                                          Your message has been successfully submitted and would be delivered to recipients shortly.