Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!BNR.CA!PWW
From: PWW@BNR.CA (Peter  Whittaker, P.W.)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re: Connections that are never released
Message-ID: <90Nov14.153424est.57509@ugw.utcs.utoronto.ca>
Date: 14 Nov 90 20:08:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 49

John,

According the post from Colin, there is no easy solution (:-<).

It is a big problem though:  we are going to release an API so that users
can write their own DUAs (it'll be a skinnier version of the QUIPU API).
Unless we kludge in an automatic timeout, we have no guarantee that the DSA
will be without clients if and when it is taken down for servicing, and that
means that we might have problems bringing it back up.

The automatic timeout is kludgeable, but I'd rather stay away from that:
some applications are bound to be dependent on fast response time once
connected - having our users handicap their applications is unnacceptable.

I haven't investigated the xselect option that Jim mentioned in his post,
but if that can be incoporated into our API, it might be an acceptable
alternative:  having the API return a descriptive X.500 error message to
the DUA application would allow the DUA to handle things in a manner
appropriate to its own needs, i.e. shutting down, timing out for X amount
of time, etc....  In any case the connection would have been cleared at both
ends.

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7

>
> Peter,
>
> We have been experiencing similar problems with ISODE connections. If a proces
s
> goes down, we have to kill all other processes that were connected to it befor
e
> we can restart the process. Even then, it can take several attempts before the
> "congestion at TSAP" clears and the process will run.
>
> I have done no research into this at present, deciding instead to put up with
it
> as an inconvenience for the time being, but like you I would be very intereste
d
> to hear from anybody who has an explanation. Is this a non-issue ? Should we b
e
> expecting such behavior ? Does anybody else regard this as a problem ?
>
>         In eager anticipation,
>
>                 JT
>