> -----Original Message----- > From: btns-bounces at ietf.org [mailto:btns-bounces at ietf.org] On Behalf Of > Mike Eisler > Sent: Thursday, July 30, 2009 3:41 AM > To: btns at ietf.org > Subject: 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? The current draft says " Implementations SHOULD create IPsec channels automatically by default when the application does not explicitly request an IPsec channel. Implemenations MAY provide a way to disable automatic creation of connection latches." Thus the application might not know what is EUNLATCHED. Would it be possible that the application gets ETIMEOUT, unless it has used a BTNS connction latching API of some sort, in which case it presumably knows about latching and can be returned an EUNLATCHED? --julien
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.