Francis,
Hi Len,
I agree with your points and would welcome a max frame size negotiation
header.
Ok, It shouldn't be a negotiation but an indication to accommodate
communication to each party.
However, whilst an intermediary might legitimately change the fragmentation
of a frame it cannot merge complete messages. If, in your example, your
client limited itself to messages of a certain size
Ok, it is important to note the peer is limiting max frame size not the
message size which may be still infinite in practical terms (63
bits)....and we have fragmentation support to deal with this.
This way intermediaries can split/coalesce fragments according to
receiving peer expectation.
then it doesn't matter
what intermediaries do to the frames as the maximum frame size would be
limited to the maximum message size that the client sends. The only time
this wouldn't work is if you were using a 'message of infinite fragments'
where you start with a fragmented frame and don't know when you'll send the
final fragment.
Assuming frame size and message size aren't equal, it does matter.
The communication between peers about maximum message sizes supported could
just as easily be in the application level protocol that you're running over
the websocket connection.
Ok, I see you point and in part you are right, but there is a risk with
this argument:
1) Protocol problems should be solved on its layer, otherwise it will
cause next layer (application level in this case) to need to solve
them. It looks reasonable not forcing people to do so.
Side note: our intention is to layer BEEP on top of websocket, so,
in practical terms this is not a problem for us because it will
provide us with all the protection and flow control required.
However it looks to me this is not a solution for people using
websocket in other contexts.
2) In general, it has lot of benefits to fragment bigger messages into
smaller pieces to avoid sick interactions.
For example, if you send a really large frame, you won't be able to
send a control message in the middle until you finish sending the
frame in place.
Having a max frame size indication will help websocket stacks to
fragment using the right value for each application.
3) No matter API style provided by a websocket stack (frame indication
or stream oriented), having framing running in the background where the
sending peer and intermediaries can coalesce frames without any
indication of the upper level will cause problems that can't be solved
in practical terms by a receiving side.
In other words, I think having a framing without a max frame size
mechanism (or other mech like ack confirmation, its the same) is like
pretending having a coin with only one side.
Len
www.lenholgate.com
-----Original Message-----
From: hybi-bounces(_at_)ietf(_dot_)org
[mailto:hybi-bounces(_at_)ietf(_dot_)org] On
Behalf Of Francis Brosnan Blazquez
Sent: 12 July 2011 15:14
To: Hybi
Cc: ietf(_at_)ietf(_dot_)org;
draft-ietf-hybi-thewebsocketprotocol(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: [hybi] Last Call:
<draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket
protocol) to Proposed Standard: request for max frame size
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(_dot_)brosnan(_at_)aspl(_dot_)es>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/hybi
--
Francis Brosnan Blázquez <francis(_dot_)brosnan(_at_)aspl(_dot_)es>
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).
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf