On Sun, 26 Oct 2014 16:22:19 GMT, Masahiro Nakagawa wrote:

Sorry for late reply.

On Mon, 20 Oct 2014 09:26:48 +0200, Sönke Ludwig wrote:

What I'm still wondering is how the client-server protocol works in this
case. Since TCP is a stream based protocol, it's necessary to have some
kind of marker for where a single message ends, either using a message
length field, using an end marker, or using the connection state (close
after each message).

Almost MessagePack libraries have streaming deserializer which processes separated / multiple MessagePack object. msgpack-d also has this deserializer.

https://github.com/msgpack/msgpack-d/blob/878fcb1852160d1c3d206df933f6becba18aa222/src/msgpack.d#L3928

We can consume the MessagePack message across TCP segments in one connection using this deserializer without length / marker. Implicit message end is connection close.

Other msgpack-rpc implementation uses same approach.

Basically there is no intrinsic way to know where the peer has stopped
writing to the connection and one has to be arbitrarily chosen.
leastSize will always block until either new data has arrived, or
until the connection is closed. dataAvailableForRead may miss data if
it doesn't get written/transferred fast enough. Using waitForData with
a finite timeout is slow and may still miss if it doesn't get written
fast enough.

So I want leastSize without blocking or returning entire message size, not 4096, method.

ok I think I found a fix, see:
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16#issuecomment-312934308