[erlang-questions] gen_tcp:recv/3 timeout

[Roberto Ostinelli]

thank you klaar,

though there's something I don't like in the proposed solution: what if you
receive more than the intended original N bytes? there's the (un)famous
undocumented option gen_tcp:unrecv but i'd rather not use it, plus there
isn't an SSL equivalent for it.

storing the additional received bytes for later usage seems cumbersome, and
sometimes even unfeasible when considering that I'm often switching the
packet type and the active options of inet.

i was thinking to wrap the gen_tcp:recv/3 function around something that
re-calls it if it timeouts, but unfortunately when it does the returned
error {error, timeout} does *not* contain the bytes received up to that
point, which then get lost.

..anyone?


On Tue, Dec 27, 2011 at 7:52 AM, Magnus Klaar <magnus.klaar@REDACTED>wrote:

> Hi!
>
> gen_tcp:recv(..., N, M) returns {error, timeout} if N bytes has not been
> received after M milliseconds. If less bytes are available the call will
> _not_ succeed. If you are receiving data at a slow rate specifying 0 as the
> length is preferrable because the call will return whatever data is
> available at the time. If there is no data available it will wait and
> timeout if no data has been received after M milliseconds. If you don't
> want to timeout at all when doing this, specify infinity as the timout
> value.
>
> MVH Magnus
>
> On Tue, Dec 27, 2011 at 2:10 AM, Roberto Ostinelli <roberto@REDACTED>wrote:
>
>> dear list,
>>
>> when calling gen_tcp:recv/3 by specifying a length and a timeout, when
>> will {error, timeout} be a response? Is it:
>>
>> 1. when no bytes are received for a period longer than the specified
>> Timeout
>> 2. when the number of bytes specified in Length is not received within
>> Timeout
>>
>> if 2, what is the best solution to actually *not* have a recv/3 timeout
>> while receiving bytes at a very low pace (for instance on very slow
>> connections)?
>>
>> thank you,
>>
>> r.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111230/3fc028da/attachment.htm>