RE: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I agree that this would be very useful. 

Would this be one frame size for both directions, or could it be specified
in each direction? 

I'm a little wary of intermediaries being allowed to adjust this unless
they're only allowed to reduce the amount...

Len
www.lenholgate.com

> -----Original Message-----
> From: hybi-bounces@xxxxxxxx [mailto:hybi-bounces@xxxxxxxx] On 
> Behalf Of Greg Wilkins
> Sent: 13 July 2011 03:54
> To: Francis Brosnan Blazquez
> Cc: Hybi; ietf@xxxxxxxx; 
> draft-ietf-hybi-thewebsocketprotocol@xxxxxxxxxxxxxx
> Subject: Re: [hybi] Last Call: 
> <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket 
> protocol) to Proposed Standard: request for max frame size
> 
> Francis et al,
> 
> not also that the protocol does support fragmentation and a 1004 frame
> too large error.
> Even the 1004 error does not carry an indication of what an acceptable
> size is, so the client/tool/intermediary that receives a 1004 will
> either have to fail or guess a smaller frames size - potentially
> binary chopping down to find an acceptable size, which might be sub
> optimal.
> 
> I simple optional header in the handshake declaring the max frame size
> (which intermediaries could adjust) would be very complimentary to the
> existing fragmentation and 1004 features and I can't think of any
> significant down side.
> 
> regards
> 
> On 13 July 2011 00:13, Francis Brosnan Blazquez 
> <francis@xxxxxxx> wrote:
> > Hi,
> >
> > Recently, I posted [1] that websocket protocol should include an
> > indication about max frame size that is willing to accept 
> the connecting
> > peer.
> >
> > Many pointed this is not an issue because you could use a stream
> > oriented API (like TCP send/recv and others), but that only 
> bypasses the
> > problem (in some cases) not solves it.
> >
> > Websocket protocol is frame based and every frame based protocol
> > designed until now has/need such feature or similar. Even 
> TCP, for those
> > that proposes to use a stream oriented API as a solution, includes a
> > more complex mechanism than a simple max frame size (window 
> based ack),
> > so each party can control/inform the sender. This is critical.
> >
> > A good example for this would be the next. Let suppose you have a
> > constrained memory device (either because it is small or because it
> > accepts a large amount of connections). On that device you deploy a
> > websocket app that only accepts small messages (< 512 bytes, let's
> > say).
> >
> > In this context, you can hard code at your web app (javascript) that
> > must not send messages larger than this size (so you 
> control websocket
> > payload size) and in the case you need to, you must split them
> > properly.
> >
> > However, even with this mechanism, you have no warranty 
> that the browser
> > or an intermediary will join those messages into a single 
> frame, causing
> > your device to receive a bigger message/frame than expected.
> >
> > Assuming this I think we would require either to include a
> > Max-Frame-Size indication (or a really poor solution: to explicitly
> > state on the draft that frames must not be coalesced by 
> intermediaries
> > or browsers).
> >
> > Regards,
> >
> > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
> > --
> > Francis Brosnan Blázquez <francis.brosnan@xxxxxxx>
> > ASPL
> > 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> >
> > AVISO LEGAL
> >
> > Este mensaje se dirige exclusivamente a su destinatario. Los datos
> > incluidos en el presente correo son confidenciales y 
> sometidos a secreto
> > profesional, se prohíbe divulgarlos, en virtud de las leyes 
> vigentes. Si
> > usted no lo es y lo ha recibido por error o tiene 
> conocimiento del mismo
> > por cualquier motivo, le rogamos que nos lo comunique por 
> este medio y
> > proceda a destruirlo o borrarlo.
> >
> > En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> > diciembre, de Protección de Datos de Carácter Personal, le 
> informamos de
> > que sus datos de carácter personal, recogidos de fuentes 
> accesibles al
> > público o datos que usted nos ha facilitado previamente, proceden de
> > bases de datos propiedad de Advanced Software Production Line, S.L.
> > (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> > rectificación, cancelación y oposición dispuestos en la 
> mencionada Ley
> > Orgánica, notificándolo por escrito a:
> > ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> > Henares (Madrid).
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> _______________________________________________
> hybi mailing list
> hybi@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/hybi
> 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]