stream in state passiveClose is still considered a connected stream?

[ArjanKn]

vibe-core/source/vibe/core/net.d

Line 580 in a646ede

return s >= ConnectionState.connected && s < ConnectionState.activeClose;

A TCPConnection.connected returns true for state passiveClose. There is no way to react to a server-side-close while waiting for data.
Shouldn;t this be changed so passiveClose is also a 'disconnected'?

[s-ludwig]

connected describes more or less the "send" direction connection state, whereas the "recv" state should usually be determined by empty. The only difference there is that empty will only reflect the actual state after the read buffer has been fully processed, which is necessary to ensure anything written by the server right before it hangs up is still properly processable.

Depending on the type of protocol, it can also make sense to use waitForData/waitForDataEx instead of empty to support a defined timeout that is different from the general TCP read timeout.

[ArjanKn]

connected is poorly/bad named. At least the documentation should be made more clear.
The empty => return leastSize == 0. Also not obvious it should/could be used to (enforced) determination of connection state.

The waitForData is currently being used with the connected intended to detect closed by peer which does not work out as expected due to the above.

Why not have full exposure of the connection state through TCPConnection?