Re: Re: Partial file sharing!!

Please try to actually use a modern Gnutella client, before you make 
assumptions. 

The List includes: 
- http://limewire.com
- http://phex.org
- http://gtk-gnutella.net (iirc)

Best wishes, 
Arne

Am Samstag, 9 de Juni de 2007 10:52 schrieb rakesh:
> Or partial file sharing is not very popular in Gnutella ?
>
> rakesh <[email protected]> wrote:                                    To
> know the partial file ranges, I have used HEAD instead of GET. The
> interesting thing is I have neither seen 206 responses nor
> "X-Available-Ranges” for HEAD request!!
>
>   Is that "Partial File Sharing Protocol Version (PFSP)" specs still hold
> true?
>
>   Regards,
>
>  Philippe Verdy <[email protected]> wrote:                                  
From [email protected]:
>   > Quoting rakesh <[email protected]> from ml.gnutella.dev-forum:
>   > > Thanks Raphael
>   > > For Gnutella as per "Partial File Sharing Protocol Version (PFSP)
>   > > 1.0", the client requests the range it wants using the Range header.
>   > >
>   > > Range: bytes=0- means the client wants any ranges the server can
>   > > provide.
>   >
>   > The PFSP specs are in error.  The above simply means you're requesting
>   > the whole file. So this Range: header is ignored and that's why you
>   > don't get a 206.
>   >
>   > > The issue is - I want to know all the parts of a file that peer
>   > > share. For that I request with "Range: bytes=0-", but none of the
>   > > peer respond with 206 and "X-Available-Ranges: " headers.
>   > >
>   > > They respond with 206 only when I specify random range in the
>   > > "Range:" headers.
>   > > That requires a range in Range header which is not known at the time
>   > > of request.
>   > >
>   > > How we can know the all the shared parts of files?
>   >
>   > You assume the file is complete and request what you need.  Then if the
>   > range is not available, you'll get a 416 and the X-Available-Range:
>   > header will tell you which parts can be requested.  Good servents will
>   > keep the connection open on a 416, so you may retry one of the
>   > advertised ranges, if any suits you.
>
>   The "Range:" header is completely described in the http specification.
> Read RFC 2616 for the exact meaning and acceptable values.
>
>   Whatever the PFSP specs says is just indicative here, as this header is
> sent as part of a regular HTTP request. In case of conflicts, the standard
> HTTP specs of the RFC are ALWAYS right when it says "MUST" or SHALL"!
>
>   Nothing in the HTTP specs indicates that the reply may ort may not
> contain a "X-Available-Ranges:" extra header (which is not forbidden).
> However the HTTP spec does not guarantee that such header will be
> transmitted through proxies and it does not describe how this extra header
> would be cached.
>
>   But here we know that we won't use caching HTTP proxies, and the PFSP
> spec may indicate that an "X-Available-Ranges:" header "should" be
> returned. (In fact, the standard HTTP protocol does not expect this header
> to be returned, as it expects that every HTTP source either has a complete
> version of the requested resource or no part of it: there's no space in
> HTTP for partial sources, not even in caching proxies).
>
>   Raphael is right when it says that a request with Range: bytes 0- means
>   requesting a whole file. It is normal to return a 206 error when the
> whole file is not available, but NOTHING forbids returning the 206 error
> with the list of available ranges, so that the requester can still request
> again only those ranges...
>
>   If you want to get only the list of ranges without downloading the whole
>   file, use the same request but with the "HEAD" verb instead of the "GET"
>   verb (the answer MUST use the same status and headers, except that the
>   client indicates that it does not want the data body immediately: you'll
> get a 206 error too if only some ranges are available, or 404 NOT FOUND
> error if nothing is available, or 200 OK if the whole file is available or
> a redirect status if some metadata is known but located somewhere else). So
> just send:
>
>    HEAD /path/resource-name HTTP/1.1
>    Host: ip1.2.3.4
>
>   You don't need to send "Range: bytes 0-" which is superfluous.
>
>   Note that HTTP/1.1 still maintains the connection by default so the reply
>   will not close it after completing the HEAD request, unless the reply
> uses the 404 NOT FOUND error, or any status above 400 (in which case, the
> server will add the header "Connection: close" in its reply to indicate to
> the client that it cannot perform another query and that it should close
> the session to the server). If the return status is lower than 400, the
> server should still accept and honor another request from the client, and
> should NOT return "Connection: close" (if the server replies with
> HTTP/1.1).
>
>   If the server replies with HTTP/1.0, it may either close the connection
>   itself (not recommended, it should better wait during at least 5 to 15
>   seconds, to give sometime to the client) or indicate to the client that
> it maintains the connection for accepting further requests (by returning
> "Connection: keep-alive" only for requests that do not complete with status
> 400 or above).
>
>   If a client receives a HTTP/1.0 reply from a server with a status at 400
> or above, it should close the connection as soon as possible after parsing
> the reply headers, to save resources on the server.
>
>   The client should do the same thing if it receives a HTTP/1.1 reply from
> a server, but only if the "Connection: close" header is present in that
> reply (the client may continue to perform a request to the server EVEN if
> the HTTP/1.1 status was 400 or more: HTTP/1.1 is better here because the
> server decides what to do and what it can accept, independently of the
> nature of the reply)
>
>
>
>
>
>  ---------------------------------
>  Luggage? GPS? Comic books?
>  Check out fitting  gifts for grads at Yahoo! Search.
>
>  [Non-text portions of this message have been removed]
>
>
>
>
>
>
> ---------------------------------
> Looking for a deal? Find great prices on flights and hotels with Yahoo!
> FareChase.
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
-- 
--
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt


[Non-text portions of this message have been removed]