[erlang-questions] HTTP requests and the meaning of eaddrinuse
Fri Jan 30 21:42:17 CET 2009
Sverker Eriksson wrote:
> Johnny Billquist wrote:
>> Sverker Eriksson wrote:
>>> Johnny Billquist wrote:
>>>> [...] you will most probably hit the limit of the number of open
>>>> file descriptors long before you exhaust all the local port numbers.
>>>> By default on on my mac, the max file descriptors is 256 (per
>>>> process). There is also a limit on the total number of file
>>>> descriptors in the OS. Nowhere near the theoretical limit of 65536
>>>> ports in tcp. So that should give you enfile or emfile.
>>> The internal TIME_WAIT state of the TCP protocol may cause exhaustion
>>> of port numbers even though the file descriptor limit is much lower
>>> than 65536. Use the netstat command tool to view lingering
>>> connections in TIME_WAIT state.
>> True, if the connections aren't closed properly.
> Actually, kind of the opposite. The peer that actively closes the
> connection by calling close() will cause its "socket" into TIME_WAIT.
> It's like a quarantine to avoid late arriving packets of the old
> connection from being confused with a new connection using the same
> port. A major flaw of TCP if you ask me.
Yes. The first side to do a close will end up in TIME_WAIT. The other
side will never. You're right.
>> But yes, that could be it. I wonder if eaddrinuse really is returned
>> in that case. [...]
> I experienced this some time ago writing a benchmark on Linux. I'm quite
> sure it was eaddrinuse that I got when the port numbers where exhausted.
Hmm. Not a good error code in that case (in my opinion). I should
probably check if other systems apart from Linux do that... Anyone know?
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the erlang-questions