[erlang-questions] gen_tcp:recv/3 timeout

Ahmed Omar spawn.think@REDACTED
Fri Dec 30 20:45:16 CET 2011

AFAIK, data doesn't get lost except if the socket is closed from the other

On Fri, Dec 30, 2011 at 6:32 PM, Roberto Ostinelli <roberto@REDACTED>wrote:

> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Best Regards,
- Ahmed Omar
Follow me on twitter
@spawn_think <http://twitter.com/#!/spawn_think>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111230/6bbe6e51/attachment.htm>

More information about the erlang-questions mailing list