RE: [core-dev] Re: Requery during downloading disabled?

"Brian Fall" <[email protected]> Tue, 23 Nov 2004 22:46:07 -0500
Newsgroups gmane.network.gnutella.limewire.core.devel
Message-ID <[email protected]>
Thanks, Greg. I thought might be a way to specify any number (well, within reason!) but 3 may be enough -- thanks again. Brian

----- Original Message -----
From: "Greg Bildson"
To: [email protected]
Subject: RE: [core-dev] Re: Requery during downloading disabled?
Date: Mon, 22 Nov 2004 11:20:05 -0500

>
> Brian,
>
> For multiple sources, you can only use "xs", "as" and "xt". With xt already
> used, you can specify 2 other exact sources.
>
> Thanks
> -greg
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Brian Fall
> > Sent: Friday, November 19, 2004 6:12 PM
> > To: [email protected]
> > Subject: [core-dev] Re: Requery during downloading disabled?
> >
> >
> > Thanks, Sam. I will then pursue the "alternate locations" and the
> > "download mesh" approach as you suggest to avoid network
> > congestion. I do, however, have a question about where to begin
> > adding my own alternate locations to the mesh. I know the exact
> > IP addresses of the sources that I want to add (they are running
> > Limewire), and would ideally want to just specify this inside the
> > magnet link instead of modify the code, but I've so far been
> > unable to figure out if that's possible. Here, for example, is
> > just one variation I've tried (I added line breaks in this email
> > to make it easier to read, but didn't actually have the breaks in
> > the link itself):
> >
> > magnet:?xt=urn:&dn=SomeMusicFile&
> > xs=http://a.b.c.d:port/uri-res/N2R?urn:sha1:&
> > http://e.f.g.h:port/uri-res/N2R?urn:sha1:&
> > http://i.j.k.l:port/uri-res/N2R?urn:sha1:&
> > http://m.n.o.p:port/uri-res/N2R?urn:sha1:&
> >
> > The idea is to load up the magnet with the sources I am certain
> > will host the file, while allowing Limewire to also search for
> > sources while these xs sources start the download. Is that
> > possible? I've tried a lot of variations on the above theme,
> > attempting to put multiple sources into the magnet, but no luck
> > -- documentation I came across in the Limewire code indicate that
> > this is possible, but is it?
> >
> > If the above isn't possible, I can always modify the source code
> > so that my sources are hard-coded (for now; early testing!) as
> > alternate locations. I see that the MagnetDownloader constructor
> > takes an array of URLs named defaultURLs; should I add them in
> > the constructor (just add my sources to the defaultURLs), or is
> > there a better place in the Limewire core code to add my own
> > alternate sources to ensure that downloading starts from them
> > initially while the rest of the network is being searched?
> >
> > With thanks again for your advice,
> > Brian
> >
> > > Message: 2
> > > Date: Fri, 19 Nov 2004 01:57:54 -0500
> > > From: "Sam Berlin"
> > > Subject: RE: [core-dev] Requery during downloading disabled?
> > > To:
> > > Message-ID: <[email protected]>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Hi Brian,
> > >
> > > What you're noticing is LimeWire's refusal to do automated
> > requerying. If a
> > > download is active, then there is no need to burden the network with a
> > > search for additional sources. Network resources are the most precious
> > > commodity LimeWire has. If queries were injected into the network for
> > > existing downloads (or even automatically for failed downloads)
> > then each
> > > node would be forced to flow control its traffic, dropping user-driven
> > > searches & results.
> > >
> > > The network-conscious way to have LimeWire attempt additional
> > sources after
> > > a download begins is by using "alternate locations" and the
> > "download mesh".
> > > The download mesh is a collection of alternate locations that
> > are hosting
> > > the given file. HTTP responses can contain a header: "X-Alt:
> > a.b.c.d:port,
> > > a.b.c.d:port, etc.." that tell LimeWire to try these sources.
> > LimeWire (and
> > > other Gnutella clients) keep track of which hosts have successfully or
> > > unsuccessfully downloaded and internally keep a list of
> > alternate locations
> > > for each file. Locations are removed from servers via reading
> > the 'X-NAlt'
> > > header, which is a list supplied by the downloader (in one of it's HTTP
> > > request headers) of locations that are no longer valid.
> > >
> > > The only drawback with alternate locations is that they're currently
> > > designed to only work with uri-res requests. That is, the alternate
> > > locations must be hosting the file at
> > > http://a.b.c.d:port/uri-res/N2R?urn:sha1: . All Gnutella clients
> > > support this, but a mod would have to be written for HTTP
> > servers such as
> > > Apache.
> > >
> > > Thanks,
> > > Sam
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:core-dev-
> > > > [email protected]] On Behalf Of Brian Fall
> > > > Sent: Friday, November 19, 2004 1:39 AM
> > > > To: [email protected]
> > > > Subject: [core-dev] Requery during downloading disabled?
> > > >
> > > > Hello everyone, I've been working with are recent Limewire
> > CVS snapshot
> > > > and noticed that when a search and attempt to download
> > finally enters the
> > > > tryAllDownloads3() method of the ManagedDownloader class that
> > it actually
> > > > stops the ability to re-query (perform any more searches for
> > that piece of
> > > > content). Specifically, it appears that when the
> > > >
> > > > while (true) { ... }
> > > >
> > > > portion of tryAllDownloads3() is entered the ability to continue
> > > > searching comes to a halt. I am attempting to optimize, if
> > possible, the
> > > > search process so that a requery can be issued even while the
> > download is
> > > > in progress. To do this, I tried to re-query from within the while
> > > > (true) loop of the tryAllDownloads3() method, but that caused an
> > > > exception and stopped it entirely.
> > > >
> > > > Is it possible, given the way Limewire is currently coded, to requery
> > > > while a download is in progress?
> > > >
> > > > On a similar note (possibly related), I noticed that when I
> > use a magnet
> > > > link that has as its "xs" source a standard Web link (not a Limewire
> > > > client, but instead a web link) Limewire will only download
> > from that web
> > > > site and won't bother to query the network. I wonder if this
> > is related to
> > > > the fact that Limewire can start the download from the web site
> > > > immediately, and in doing so it enters tryAllDownloads3() before it
> > > > actually has a chance to query the Gnutella network? Following, for
> > > > example, is the type of magnet link that I try (not a real
> > one) but for
> > > > which only one source is allowed (that source being the
> http:// web site;
> > > nothing from the Gnutella network is available):
> > >
> > >
> > >
> magnet:?xt=urn:sha1:EI66YQYRH47K73NNFPSQDUV&dn=SomeMusicFile&xs=http://som
> > > where.com/path/thefile.mp3
> > >
> > > Magnet's such as the above only download from the web site specified by
> > > xs, but don't use the Gnutella network -- is that related to the issue
> of
> > > re-query being disabled during downloads or do you think these are two
> > > separate issues?
> > >
> > > Ideally I'd like to specify a number of sources for xs (so that the
> > > download can start from multiple web sites), which Limewire will use to
> > > start the download while it queries the larger Gnutell network. Is this
> > > possible given the way Limewire is designed today?
> > >
> > > With thanks for any advice you might have on these two issues,
> > >
> > > Brian
> > > --
> > > ___________________________________________________________
> > > Sign-up for Ads Free at Mail.com
> > > http://promo.mail.com/adsfreejump.htm
> > >
> > >
> > > _______________________________________________
> > > core-dev mailing list
> > > [email protected]
> > > http://www.limewire.org/mailman/listinfo/core-dev
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > core-dev mailing list
> > [email protected]
> > http://www.limewire.org/mailman/listinfo/core-dev
> >
> >
> > End of core-dev Digest, Vol 6, Issue 6
> > **************************************
> >
>
> --
> ___________________________________________________________
> Sign-up for Ads Free at Mail.com
> http://promo.mail.com/adsfreejump.htm
>
>
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>
>
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>

--

___________________________________________________________
Sign-up for Ads Free at Mail.com

http://www.mail.com/?sr=signup

_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev