From: djarrett@gandalf.ca (Dave Jarrett)
Subject: Re: TCP/IP over ISDN
Organization: Gandalf Data Ltd., Nepean, Ontario
Date: Thu, 27 Aug 1992 18:23:48 GMT

In article <tb.714899933@materna> tb@Materna.DE (Torsten Beyer) writes:
>Hi Folks,
>
>I have a problem concerning TCP/IP over ISDN. We have an ISDN implementation
>for TCP/IP that is able of a so called short hold mode. This means, ISDN
>connections that are idle for a certain time get closed without closing the
>overlaying TCP connections. As soon as one of the communication partners
>starts sending data again, a new ISDN connection is established. All this
>happens (nearly) transparently to the IP layer.
>
>However there is a problem: How can a server tell wether an established
>connection is still established or already broken due to a crash on the
>client side. We don't want to poll clients (i.e. ping) since this would
>actually break the cost advantage of ISDN short hold mode.
>
>From my point of view the only way a server can tell a connection is
>broken, is when the same client sends a SYN from the same client port to the
>same server port. Is this true or are there other ways of detecting that a
>connection is broken (or was broken) ?
>--
>Torsten Beyer                      	mail	     : tb@Materna.DE
>Dr. Materna GmbH		   	vox humana   : +49 231 5599 225
>Vosskuhle 37, D-4600 Dortmund	   	fax machina  : +49 231 5599 100
> "There must be a place, under the sun, where hearts of olden glory grow young"


As far as I know, there is no way of implicitly determining the
difference between a client on hold and a client that has been powered
off. The only way for the server to determine if a disconnected client
is still capable of receiving traffic, is to poll the client.

A polling method that appears to be very cost effective might 
work as follows:

 - The ISDN server maintains a idle timer for each client LAN connection.
   If data packets are received from the client within the preprescribed 
   period of time, no poll will be neccessary. 

 - When the idle timer expires, the ISDN server issue a B-channel 
   connect request to the client ISDN station. The user-user data field
   in the connect request contains a "poll" command. 

 - If the client is still alive, it returns a "disconnect" response to
   the connect request with predefined user "cause" value. 

 - Receipt of a disconnect response, with a user rejection code, 
   informs the server that the client is still alive and capable of
   receiving LAN data.

 - If the server receives a disconnect response with any other "cause"
   code, it knows that the client has been powered off or disconnected. 

This approach has two advantages over polling using SYNs:

 1. No connection is ever established during the polling process,
    so no connection tariffs are applicable.

 2. This approach is LAN protocol independant.


This approach depends on the availability of user-user data in the
connect request. If your local PTT does not support user-user data, 
it might be possible to issue the connect request with a specific,
predefined DDI (extension number) used only for polls. 

If anyone has reason to believe that this approach will not work, or 
can think of viable alternative approaches, feel free to comment. 

It might be a good idea to post your question to the comp.dcom.isdn newsgroup,
where all the real ISDN gurus are.

Regards,
Dave J.



Newsgroups: comp.protocols.tcp-ip,comp.protocols.ibm,comp.sys.novell