gen_tcp bug ?

[Per Hedeland]

Raimo Niskanen <raimo@REDACTED> wrote:
>
>I confirm this behaviour, and I regard it as a bug that I am about to
>fix. Not being a socket guru myself I wonder, what is the expected
>behaviour of gen_tcp:recv(Fd, N) when there are less than N
>bytes in the receive buffer but more than 0?
>
>a) To return with the available bytes.
>b) To wait until there are N bytes, but if the socket gets closed
>   or some error occurs return with the available bytes and let 
>   subsequent calls indicate the error.
>
>My guess is b) but I would like a second opinion.

Well, my opinion is that it's obvious that the semantics of
gen_tcp:recv() are *intended* to be different from Unix read() (as bengt
explained), since you can get read()-like semantics with Length = 0.
I.e. it *is* an error condition if you request 100 bytes and this
request can't be fulfilled - just returning {ok, Packet} in that case
would be wrong.

I would imagine that people use gen_tcp:recv() with Length /= 0 to
implement their own "packet" schemes - i.e. recv() the header (with
fixed length), extract the length of the data from that, and recv()
exactly the data. If you make the change Klacke wants, you'll break
such code - it becomes necessary to check the amount of data returned by
each recv().

I'm not sure it's a good idea to return an error *and* the remaining
bytes though - so my vote (FWIW) would probably be that the current
behaviour is correct.

--Per