I doubt you really need to put something like this explicitly in a
spec. If a client choose to advertise less available ranges to a
certain requester, then that should be fine.

On Apr 18, 2009, at 2:21 PM, Raphael_Manfredi@... wrote:

>
>
> Quoting Arne Babenhauserheide <arne_bab@...> from
> ml.gnutella.dev-forum:
> :The texts overally looks good, but the extension is problematic for
> Phex:
> :
> :Phex uses the X-Available-Ranges to compute the most common and
> least common
> :segments, so it can start the download with the least common
> segment, and the
> :chance of getting the whole file when some uploaders drop out
> increases.
> :
> :Your change will make this pointless, since we can't know the
> rarest segment
> :anymore, as soon as even one segment is omitted.
> :
> :Is there another motivation for this change besides saving bandwidth?
>
> The sole motivation of this change is simply to save bandwidth when
> "bad"
> clients request a highly fragmented file without honouring the Retry-
> After
> indication given for that file. Some clients will retry every minute
> even
> though the Retry-After header states 20 minutes.
>
> Note that gtk-gnutella has been omitting chunks from X-Available-
> Ranges
> since the beginning of PFSP, but this was not documented, and I hadn't
> invented the X-Available header yet...
>
> I do not believe this is problematic for Phex, in that it is trivial
> to
> see that a client has limited its X-Available-Range emission (by
> comparing
> the sum of advertized bytes there with the ones in the X-Available
> header),
> and successive requests to the same server will likely return
> different
> chunks (selection of returned chunks is random). After some
> requests, you
> will have complete knowledge of the available ranges.
>
> I suggess you leave out the servents from which you have only an
> incomplete
> knowledge of the available chunks for the purpose of the rarest chunk
> compuation, and you'll be fine.
>
> Raphael
>
>