home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / tcpip / 4212 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.5 KB  |  87 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!cs.utexas.edu!torn!cunews!hobbit.gandalf.ca!djarrett
  3. From: djarrett@gandalf.ca (Dave Jarrett)
  4. Subject: Re: TCP/IP over ISDN
  5. Message-ID: <1992Aug27.182348.19584@gandalf.ca>
  6. Organization: Gandalf Data Ltd., Nepean, Ontario
  7. References: <tb.714899933@materna>
  8. Date: Thu, 27 Aug 1992 18:23:48 GMT
  9. Lines: 76
  10.  
  11. In article <tb.714899933@materna> tb@Materna.DE (Torsten Beyer) writes:
  12. >Hi Folks,
  13. >
  14. >I have a problem concerning TCP/IP over ISDN. We have an ISDN implementation
  15. >for TCP/IP that is able of a so called short hold mode. This means, ISDN
  16. >connections that are idle for a certain time get closed without closing the
  17. >overlaying TCP connections. As soon as one of the communication partners
  18. >starts sending data again, a new ISDN connection is established. All this
  19. >happens (nearly) transparently to the IP layer.
  20. >
  21. >However there is a problem: How can a server tell wether an established
  22. >connection is still established or already broken due to a crash on the
  23. >client side. We don't want to poll clients (i.e. ping) since this would
  24. >actually break the cost advantage of ISDN short hold mode.
  25. >
  26. >From my point of view the only way a server can tell a connection is
  27. >broken, is when the same client sends a SYN from the same client port to the
  28. >same server port. Is this true or are there other ways of detecting that a
  29. >connection is broken (or was broken) ?
  30. >--
  31. >Torsten Beyer                          mail         : tb@Materna.DE
  32. >Dr. Materna GmbH               vox humana   : +49 231 5599 225
  33. >Vosskuhle 37, D-4600 Dortmund           fax machina  : +49 231 5599 100
  34. > "There must be a place, under the sun, where hearts of olden glory grow young"
  35.  
  36.  
  37. As far as I know, there is no way of implicitly determining the
  38. difference between a client on hold and a client that has been powered
  39. off. The only way for the server to determine if a disconnected client
  40. is still capable of receiving traffic, is to poll the client.
  41.  
  42. A polling method that appears to be very cost effective might 
  43. work as follows:
  44.  
  45.  - The ISDN server maintains a idle timer for each client LAN connection.
  46.    If data packets are received from the client within the preprescribed 
  47.    period of time, no poll will be neccessary. 
  48.  
  49.  - When the idle timer expires, the ISDN server issue a B-channel 
  50.    connect request to the client ISDN station. The user-user data field
  51.    in the connect request contains a "poll" command. 
  52.  
  53.  - If the client is still alive, it returns a "disconnect" response to
  54.    the connect request with predefined user "cause" value. 
  55.  
  56.  - Receipt of a disconnect response, with a user rejection code, 
  57.    informs the server that the client is still alive and capable of
  58.    receiving LAN data.
  59.  
  60.  - If the server receives a disconnect response with any other "cause"
  61.    code, it knows that the client has been powered off or disconnected. 
  62.  
  63. This approach has two advantages over polling using SYNs:
  64.  
  65.  1. No connection is ever established during the polling process,
  66.     so no connection tariffs are applicable.
  67.  
  68.  2. This approach is LAN protocol independant.
  69.  
  70.  
  71. This approach depends on the availability of user-user data in the
  72. connect request. If your local PTT does not support user-user data, 
  73. it might be possible to issue the connect request with a specific,
  74. predefined DDI (extension number) used only for polls. 
  75.  
  76. If anyone has reason to believe that this approach will not work, or 
  77. can think of viable alternative approaches, feel free to comment. 
  78.  
  79. It might be a good idea to post your question to the comp.dcom.isdn newsgroup,
  80. where all the real ISDN gurus are.
  81.  
  82. Regards,
  83. Dave J.
  84.  
  85.  
  86.  
  87.