[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, July 27, 2009 10:01 am, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>     >> My conclusion is that the API ought to provide information for
>     >> the application about the connection latching, and it just does
>     >> not seem to be there.  If you can point me to a discussion of
>     >> this topic on the WG mail list, then I'll clear.  I'm not trying
>     >> to alter consensus, but I do want to make sure that this topic
>     >> was considered.
>
>     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.
>
>   However, an application might know what to do with ETIMEOUT, while it
> would not know what to do with EUNLATCHED or some such....

Isn't the application the entity that decided to enable latching?  If so,
the application (or its author) needs to be prepared to deal with new
error indication.

If not, what is the model for enabling latching?
>
> - --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
> ]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby
> guy");  [
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSm3dYoCLcPvd0N1lAQLnNQf8CNCa4TWJY5I/TvtAH4+eyLbHzyO+I/dp
> /l5Zcs3Ld16qhYh9OeWogBT2wCeicdx3cL1PdoyibTOfMw/PPxUSY+HKWyR78Ky5
> afHA8JxRypvpLqULU7i2jCfwNJZbQi4wojPYl9oeQGAKKmwX3hsBQxKtWY5OWLh+
> ExHXfZpGfvauG+LVYHMSNATJEveESpgqRXQyxUqGEChblWVFANHjX/OLJTRCZ7vQ
> xXhI2rGIlBOwl9ssAx4vejDR0js8vQ98RXy7XiVJhGZq6+hklOuZfmW44T4iHUNk
> emB7EpEWwO7MshVPRCxARIXjICaG2xnQ0XR9ZwSvbtNMsS1vCGVeVg==
> =5max
> -----END PGP SIGNATURE-----
> _______________________________________________
> btns mailing list
> btns at ietf.org
> https://www.ietf.org/mailman/listinfo/btns
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.