Re: [jetty-dev] [SPDY] partial transmission of data frames due to small

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Wed, May 30, 2012 at 6:08 AM, Oliver Senn <oliver.senn@xxxxxxxxxxxxx> wrote:
> Hello list,
>
> I recently started using jetty-SPDY for pushing data from a server to a
> client. Yesterday however, I discovered that under heavy load (i.e. the
> server sending data in a loop without waiting), the flow control of SPDY
> kicks in and the window size goes from 64K bytes more and more towards 0
> bytes, eventually reaching it.
>
> My test server [1] sends small data frames with a data size of 56 bytes.
> Once the window size is smaller than this, it continues to send data thereby
> truncating data frames. The client then receives not the whole message
> anymore in one call of the onData() method.
>
> I wanted to ask whether this behavior is the desired one and whether it is
> consistent with the SPDY specification [2] since it states in section 2.6.8
> (WINDOW_UPDATE), "[...] The sender must not send a data frame with data
> length greater than the transfer window size. [...]"?
>
> Shouldn't the server just pause until the window size is again big enough to
> allow sending the whole data frame?

What you would like is that SPDY preserve *message* boundaries (i.e.
your 56 bytes message), but there is nothing in the spec that
guarantees that, plus it would be impossible in case of messages
larger than the window.
Therefore SPDY does not guarantee that message boundaries are preserved.

Note that message boundaries are different from frame boundaries: you
can send a 56 bytes message, which can be framed in 28 2-bytes spdy
data frames (it's an extreme, inefficient case, but not forbidden by
the spec).
Furthermore, nothing forbids implementation to coalesce messages (but
we don't do that).

You have to come up with your own framing, if you're going to send
down messages like in your example, or use push streams, closing the
stream after each message (although there is an overhead - one more
SYN_STREAM frame).
Another solution could be to send your 56 bytes message followed by a
0 bytes data frame; on the client you will accumulate until you get
the 0 bytes data frame, at which point you know that what you
accumulated is "complete".

We may propose a message boundary flag for spdy/4.

Simon
-- 
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz