Re: [btns] Q: How to deal with connection latch breaks?

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Mon, Jul 27, 2009 at 01:01:23PM -0400, Michael Richardson wrote:
>     Nicolas> APIs are nice, but existing apps won't use them until
>     Nicolas> updated, and anyways, connection latching adds value even
>     Nicolas> without adding APIs, which means we need a default response
>     Nicolas> to latch breaks in the absence of new APIs (either because
>     Nicolas> not implemented or not used).
> 
>   So, errno value from write(2) is not a new API.
>   A new errno value should provide enough information, I think.

If an API's definition has a closed set of error codes, then no.  That
said, I believe that's not the case for write(2) and friends.  And, of
course, there may be implementors for whom it's not possible to add new
error codes for existing APIs, thus we must provide a recommendation or
requirement for such implementors.

>   However, an application might know what to do with ETIMEOUT, while it
> would not know what to do with EUNLATCHED or some such....

There's nothing unreasonable about returning ECONNRESET (an existing
error) when the latch breaks IF the application did not use any APIs to
indicate that it knows about latching.

If the errno set for I/O syscalls is not a closed set then there's also
nothing unreasonable about adding EUNLATCHED.

Note that if a latch never breaks then the connection should never
reset.  So EUNLATCHED would only distinguish latch breaks from peer
reboots -- not exactly Earth shaking for an application that is unaware
of latching in the first place.  But for apps that use new APIs
distinguishing latch breaks is important.

I think I/O syscalls return ETIMEDOUT when SO_KEEPALIVE is set and the
connection times out.  Again, distinguishing timeout from latch break in
the application-is-not-using-new-APIs case doesn't seem all that
important.

Nico
--