Re: [hybi] Framing Take VI (a compromise proposal)

[Takeshi Yoshino <[e-mail]>]

2010年8月16日13:28 Greg Wilkins <[e-mail]>:

> 2010/8/16 Ian Fette (イアンフェッティ) <[e-mail]>:
> > On Sun, Aug 15, 2010 at 8:44 PM, Greg Wilkins <[e-mail]> wrote:
> >>
> >> Ian,
> >>
> >> thanks for the proposal.
> >>
> >> It appears that the total message length is mandatory if fragmentation
> >> is used, however I believe that one of the use-cases for fragmentation
> >> is to send dynamic messages where the total length is not known in
> >> advance.   Could we make message length optional somehow?
> >>
> >
> > It is optional. %x0000000000000000 ; complete message length is unknown
> (iff
> > initial==1 && final==0) -- suggestions as to how to make that clearer
> most
> > welcome.
>
> Sorry my bad. I see it in the BNF now.
>
> It does feel a little funny to be byte squeezing other lengths and
> then to send 8 zeros to say unknown.  To be consistent, we should
> either just always send lengths in full or always make an attempt to
> squeeze.
>
>
>
> >> Alternately, message length (in bytes and/or in characters etc.) is
> >> just one example of meta-data.  Would it not be possible to support
> >> that in a standardized meta data extension?
>
> any thoughts on this?
>
>
it also sounds ok to me.



> >> If we are to have per frame extension data, then I think having the
> >> extension length in the header so simple implementations can skip is a
> >> good approach.  However, I think we probably would also need to goto
> >> extra detail about how data from multiple extensions would be
> >> separated within the extension data.
> >>
> >> However, I remain a little concerned that having both op-code and per
> >> frame extension data could result in some contradictory data.  For
> >> example, if we have an op-code for final frame, then it is likely that
> >> intermediaries will know that frame and possibly use it as part of
> >> shutting down the connection (with half closes etc.).  If we then have
> >> an extension that provides multiplexing and allows a channel ID to be
> >> associated with every frame, what does it mean to have a final frame
> >> op code extended with a channel ID?
> >
> > I would assume it means that a complete message has been sent, but that
> the
> > channel remains open. E.g. I have two channels open, the fact that I've
> sent
> > a complete message on one channel shouldn't be taken as an indication
> that
> > I'm done sending messages on that channel. Even in the non-multiplexing
> > case, the fact that you've received a full message doesn't mean the
> > connection should be shut down. That's the point of "persistent" :)
>
> Sorry I think you have misunderstood my scenario.  By Final frame, I
> was not meaning the final frame as indicated by the bit in your frame
> header, but the final frame op-code that we have previously discussed
> as one of the potential op-codes (text-data, biinary-data, ping, pong,
> final frame, etc).   The final frame op-code has been proposed to half
> close a connection - ie no more frames will be sent after a final
> frame.  There is such an op-code in the current -00 proposal already.
>
>
>
I feel like that kind of "logical" half closing should be dealt with by
multiplexing extension level by raising
some bit or some mux op-code in extension bits for mux protocol to tell that
channel X is half closed by
client.

Such final frame op-code in standard WebSocket framing (core protocol)
should not be diverted for indicating closing some of mux-ed channels.

That said, we're saying that complete message length field means the size of
messages in mux-ed channel.
Yes, this is also "logical" information for mux-ed channels.
Letting two meta-data (the followings) both in standard WebSocket framing
(core protocol) have meanings for
different level sounds a bit complicated. Good point.
- complete message length : to tell complete message length of messages
in mux-ed logical channel,
- op-code : to tell encapsulating real WebSocket channel


> So to restate my concern, I'm worried that per frame extension data
> and core protocol op-codes may not be entirely orthogonal. Some
> extensions may be very meaningful for some op-codes, but not others.
>
> To flip this around to a question - can you say why you need extend
> every frame?   if there are ping, pong and final frame op-codes
> defined, what is the use-case to extend them?  I can see the good
> use-cases for extending frames with text and binary op-codes, but that

could be done with just a extended-text and extended-binary op-code?
>
>
i'm flexible with combining or separating EXT from op-code. If we have
op-codes for which extension doesn't make sense,
your idea looks better in terms of utilization.

if we define EXT bit separately, when new op-codes are added in the future,
old implementation still can know that there's
extension in that frame. op-code is unknown for that implementation, so i'm
not sure if this is really useful.

Thanks,


> cheers
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>