Am 08.03.2014 11:19, schrieb hardcoder:

On Sat, 08 Mar 2014 01:42:13 GMT, Etienne Cimon wrote:

Hope it helps!

1) I don't know the length of the data upfront. Normally I would go with this solution but it is broken too as reading in while loop never leaves conn.read()
as it tries to read even if there is nothing. This is broken:

leastSize is probably the function you need to use here - it returns
the amount of data that is known to be available for reading. It will
block though, until some data is available, so if you need to
completely avoid blocking, use dataAvailableForRead or waitForData,
as Etienne suggested:

if (conn.dataAvailableForRead) {
   auto buf = new ubyte[conn.leastSize];
   conn.read(buf);
   // ...
}

Why is this so difficult? IMHO readAll() is broken. Why would one ever possibly want a connection to close to signalize eof? It is super easy to send conn InputStream back, why is buffering this data so difficult?

In fact, disconnecting is the only thing that can reasonably signal EOF
for a TCP connection. If you want packet based messaging, use UDP,
message pack, a custom header with the message length, or similar means
to split up the data stream into logical units.

The alternative is to use waitForData/dataAvailableForRead with a
small timeout value, as Etienne suggested, but beware that this can
yield any fraction of the data stream that the client has sent and not
necessarily a logical part of it - there is no way to know this on the
TCP protocol level.