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

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



>>>>> "Julien" == Julien Laganier <Laganier> writes:
    Julien> Sorry I messed up. It should read:

    Julien> ETIMEOUT be returned to the application that didn't used a
    Julien> BTNS API to request the connection be broken when the latch
    Julien> transition to BROKEN, and ELATCHBROKEN otherwise (i.e., the
    Julien> application did use the BTNS API and thus knows what a
    Julien> BROKEN latch and ELACTHBROKEN are, and what to do.)

I concur.
Let's write:
      ETIMEOUT SHOULD be returned to applications when a broken connection
      latch causes communications to fail.  This is consistent with what
      would happen if a cable was unplugged, etc.

      Applications which have used a BTNS API to request a latched
      connection MAY receive a more detailed error to indicate if 
      the communication failure is a result of a connection latch
      being broken.  The details of this process are defined in an API
      document.

(I am hoping that we can find a way to avoid a direct reference to the
API document, as that would hold things up further)

-- 
]     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");  [


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