Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1998-09-16
2001-10-16
Rinhart, Mark H. (Department: 2756)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C714S004110
Reexamination Certificate
active
06304905
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to telecommunications. The invention relates more specifically to apparatus and methods for allowing either a client or host, which are communicating by way of an access server during a remote session, to know when the other has gone offline.
BACKGROUND OF THE INVENTION
Many telecommunication functions require computer users to connect to remote services to retrieve or transmit information. Increasingly, these remote services arc accessed using an asynchronous dial up connection. This class of functions may include, but is not limited to, dial up connections to the Internet, connections to bulletin boards, connections to internal and external databases and sending and receiving faxes. These functions are carried out during interactive, character-oriented communication sessions via a modem. This is typically known as outbound modem dialing.
To support remote login sessions, various computer manufacturers have developed facilities that allow their users to log in remotely from one computer to another. Within the Internet, the most commonly used method is a facility called “telnet,” which is the name of the protocol used to support remote login sessions and also the name of the Transmission Control Protocol/Internet Protocol (“TCP/IP”) remote login program. TCP/IP refers to the suite of protocols that define the Internet. Originally designed for the UNIX™ operating system, TCP/IP software is now available for every major kind of computer operating system. To be on the Internet, a computer must have TCP/IP software. The telnet protocol defines how local and remote computers talk to each other to support a remote login session. A more complete discussion of remote login using telnet is described in D. Dem, “The Internet Guide For New Users,” pp. 247-67 (McGraw Hill 1994).
Many computer users are connected to the Internet by access servers on local area networks or enterprise networks. An example of an access server is model number (AS5200), commercially available from Cisco Systems, Inc. To help defer the cost of installing and maintaining additional phone lines, which may be used very little per user, many equipment manufacturers have added the ability to establish remote sessions on the outbound ports of access servers and routers. These remote sessions are supported by an embedded telnet protocol operating in conjunction with other communication software, such as a communication port director.
To support remote sessions via an access server, as opposed to a direct personal computer/remote service connection, the telnet protocol has undergone revision. The name and the result of the process for disseminating information about a proposed standard on the Internet is known as Request for Comments (“RFC”). The standards are currently proposed and published on-line at http:http://info.intcrnet.isi.edu/innotes/rfc/files/rfc2217.txt.
In RFC 2217, entitled “Telnet Com Port Control Option” and published in Oct. of 1997, the present inventor identified three new areas of functionality within the telnet protocol which needed updating to successfully support the needs of outbound modem dialing. A first new function is the ability for a client to send corn port configuration information to an access server which is connected to the outbound modem. This ensures that data transmitted and received by the modem is formatted correctly at the byte level. A second new function is the ability for an access server to inform a client of any modem line or signal changes, such as carrier detect (RLSD) changes. This information is vital, since many client software packages use this information to determine if a session with a remote service has been established. The third new function provides the ability to manage flow control between the client and the access server which does not interfere with the flow control mechanisms used by the session between the client and the remote service.
The first new function is carried out by causing a client and server to negotiate a corn port configuration by exchanging messages. The negotiation of the corn port control option protocol uses the standard telnet negotiation protocol mechanism. This mechanism involves the exchange of messages that request an action (a “DO” or “DON'T” messages) and messages that respond to such requests (“WILL” or “WON'T” messages). RFC 2217 identifies the following negotiation messages having the following meanings:
IAC WILL COM-PORT-OPTION
The sender of this command is willing to send corn port control option commands.
IAC WONT COM-PORT-OPTION
The sender of this command refuses to send corn port control option commands.
IAC DO COM-PORT-OPTION
The sender of this command is willing to accept corn port control option commands.
IAC DONT COM-PORT-OPTION
The sender of this command refuses to accept corn port control option commands.
The client can send these commands at any time and at multiple times throughout a telnet session. Each command transmitted from the client to the access server must be acknowledged once the command has been processed by the access server. This confirmation informs the client of the value set at the access server after the processing of the command. This acknowledgment is not used to acknowledge the receipt of the command, which is handled at the TCP protocol layer. Its purpose is to inform the client of the value in use, which may be different than the value requested in the client's command. For example, the client may request a baud rate higher than the access server can provide. If the client does not receive an acknowledgment within a reasonable time, the client may wish to re-send the command or terminate the session.
Once DO and WILL commands have been negotiated, the client may send any of the following Com-Port Control Option commands:
Client
Access
Command Name
to Access Server
Server to Client
SIGNATURE
Text
Text
SET-BAUDRATE
1
101
SET-DATASIZE
2
102
SET-PARITY
3
103
SET-STOPSIZE
4
104
SET-CONTROL
5
105
NOTIFY-LINESTATE
6
106
NOTIFY-MODEMSTATE
7
107
FLOWCONTROL-SUSPEND
8
108
FLOWCONTROL-RESUME
9
109
SET-LINESTATE-MASK
10
110
SET-MODEMSTATE-MASK
11
111
PURGE-DATA
12
112
The following format may be used to send the commands: IAC SB COM-PORT-OPTION COMMAND NAME<value>IAC SE or IAC SB COM-PORT-OPTION COMMAND NAME<text>IAC SE. “IAC” means Interpret As Command, and is defined for use in Telnet in RFC 854, character decimal code 255; “SB” means Subnegotiation Begin, and is defined for character code 250; “SE” means Subnegotiation End, and is defined for character code 240. The Command Name can be any one of those listed above with the appropriate value or text inserted.
If a client sends a command and there is no acknowledgment by the access server within a reasonable time, the client may wish to re-send the command or terminate the session to save system resources. Generally, a reasonable time period to re-send or terminate would be twice the delay acknowledgement (“delay ack”) timer in TCP/IP If the delay ack timer is ten seconds, then the client would wait approximately 20 or 30 seconds before re-sending or terminating. This 20-30 second time period ensures that commands will not be re-sent or that the receiver will not be terminated unnecessarily in the event that the receiver is only slowing down or interrupted temporarily.
Unfortunately, when telnet operates as an embedded protocol to support remote TCP/IP sessions, there is no efficient way for either a client or an access server to know when a client or server at the opposite end of the connection has gone offline. In a past approach, a user would execute telnet using a terminal interface, so that the user could type commands to the telnet program and view responses by the remote system. In this past approach, there are visual cues to indicate when either the client or access server had gone off-line. If a user of the client, a PC user for example, depressed a key at the client machine and received no response, the user could surmise that the host had gone offline,
Cisco Technology Inc.
Hickman Palermo & Truong & Becker LLP
Jaroenchonwanet Bunjob
Palermo Christopher J.
Rinhart Mark H.
LandOfFree
Detecting an active network node using an invalid protocol... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Detecting an active network node using an invalid protocol..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Detecting an active network node using an invalid protocol... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2597352