[zeromq-dev] accept() and EMFILE/ENFILE

[Martin Sustrik]

Hi Dhammika,

> True, this adds complexity. But I don't think this affects server's state.
> Server has to handle client immediately closing its socket after tcp
> handshake anyway. Client timing out and closing its socket is not very
> different. In both cases server's accept() will return ECONNABORTED.

Good point. Ok, let's keep this issue open till it's actually 
implemented. The best solution will pop up when we start messing with 
the code.

>>>>> Also closing the listening socket sends ECONNREFUESED to new
>>>>> connection requests, this is a hard tcp error.
>>>>> How does the client know if the server is temporarily busy or not
>>>>> running at all? Client can query zmq_server, but then aren't we going
>>>>> to endup with one of those byzantine problems?
>>>> My feeling is that both out-of-sockets and component-not-running should
>>>> be
>>>> handled in the same way, specifically by attempt to reconnect after a
>>>> while.
>>>>
>>> Isn't it better to draw a distinction and let the application decide?
>> Dunno. Can you think of a real-world use case where it makes sense to handle
>> network-outage and out-of-sockets errors in different manner?
>> 
> How about email?
> An invalid address returns a permanent error, but if the MTA is out of
> resources ie. out of disk space returns a transient error.

Yes, the distinction makes sense for email. There's different behaviour 
associated with each case (e.g. retry on out-of-disk, deliver a bounce 
on invalid address). I'm not sure there's any point is associating 
different behaviour with out-of-sockets and network-failure though.

Martin