On Wed, 05 Jul 2017 17:03:40 GMT, Sönke Ludwig wrote:

On Tue, 04 Jul 2017 19:57:58 GMT, Timothee Cour wrote:

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


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

ok I think I found a fix, see:

There is one thing that I don't yet understand about that read loop. Just to make sure that there is no misunderstanding somewhere, input.connected can return a different value from !input.empty. .empty (same as .leastSize == 0) specifically signals that the connection was closed by the remote and that there is no more data in the read buffer. .connected returns the physical connection state as seen from the local peer. As a rule of thumb, .connected should be used to test write-readiness and .empty to test for read-readyness.

In this case, .connected is used together with .leastSize/read, meaning that the loop will possibly exit before all data has been read. But that doesn't fit with the initial issue description that it blocks in leastSize. I think I'll have to see the expected sequence of the data exchange between client and server to make a guess of how this should really look like.

But if the meaning of _unpacker.size is as I imagine (couldn't find the definition anywhere), then the loop should probably look like this:

do {
    size_t len = _input.leastSize;
    // NOTE: leastSize == 0 signals that the remote has closed the connection
    enforce(len == 0, "Connection closed before a full message was written.");

    auto data = new ubyte[](len);
} while (_unpacker.size > 0);