RE: Re: Partial file sharing!!

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]