Re: Git Issues: PING

[James M Snell <[e-mail]>]

I'm working through issues relating to frame size currently. What I'd
like to recommend is that the PING frame be limited to no more than
8-bytes of payload data. The PING sender can use these bytes however
they want and they are completely opaque to the PING recipient. Most
typically, I would think that these bytes would be used to encode a
timestamp or correlation ID for the ping.

On Mon, Apr 22, 2013 at 12:43 PM, Jeff Pinner <[e-mail]> wrote:
> I would be cautious of giving semantic meaning to the payload, and an ID
> larger than 4 bytes seems unnecessary.
>
> I do like the introduction of the PONG flag and the subsequent removal of
> the restrictions on the ID field, letting the peer send whatever index into
> their stored context that they like.
>
>
> On Sat, Apr 20, 2013 at 2:56 PM, James M Snell <[e-mail]> wrote:
>>
>> The main argument I've seen for allowing a payload is so that the PING
>> sender can include a stronger correlation token than just the ID (a
>> timestamp, for instance).
>>
>> On Sat, Apr 20, 2013 at 1:51 PM, William Chan (陈智昌)
>> <[e-mail]> wrote:
>> > +jpinner who filed the issue
>> >
>> > Unless anyone comes up with a motivating reason to add arbitrary
>> > payloads,
>> > let's just disallow them. This is what the SPDY/2 spec originally did
>> >
>> > (http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-PING)
>> > "Length: This frame is always 4 bytes long."
>> >
>> > Unless I missed a PING discussion elsewhere, it looks refactoring
>> > accidentally introduced a semantic change. Let's fix that.
>> >
>> >
>> > On Sat, Apr 20, 2013 at 12:37 PM, James M Snell <[e-mail]>
>> > wrote:
>> >>
>> >> Per https://github.com/http2/http2-spec/issues/68 ...
>> >>
>> >> The question is: "In the current draft, the PING frame requires the
>> >> server to resend an arbitrarily large payload.... Perhaps restrict the
>> >> length of the PING frame to 0, allow any stream identifier in the
>> >> header require the server to echo the identifier? ... I'm not sure
>> >> what benefit being able to echo arbitrary contents provides."
>> >>
>> >> Placing a cap on the size of the Ping payload makes sense. Whether
>> >> that cap should be strictly mandated by the spec or established via
>> >> SETTINGS is an open question, however. Perhaps the spec ought to place
>> >> a strict upper limit and allow recipients to optionally specify a more
>> >> restrictive value via SETTINGS?
>> >>
>> >> - James
>> >>
>> >
>
>