Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer handshaking
Reexamination Certificate
1998-12-01
2002-02-12
Winder, Patrice L. (Department: 2155)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer handshaking
C709S224000, C709S227000, C714S025000
Reexamination Certificate
active
06347339
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to telecommunications. The invention relates more specifically to apparatus and methods for allowing a first node of a network, which is communicating with a second node, to know when the second node has gone offline.
BACKGROUND OF THE INVENTION
Many telecommunication functions require computer nodes or servers to connect to remote nodes or servers to retrieve or transmit information. Increasingly, these remote servers are 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 communication sessions according to an agreed-upon protocol.
An example of a system that communicates in this manner comprises an Access Control Server and a Network Access Server, both of which are commercially available from Cisco Systems, Inc., and which communicate using protocols called TACACS+or RADIUS. The term “node” refers broadly to a computer or computer device of any kind that communicates within a network, such as a server, client or workstation, router, or switch.
To support remote login sessions, and for other reasons, certain computer facilities allow 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 urlinfo.internet.isi.edu/in-notes/rfc/files/rfc2217. txt.
A first computer connects to a second computer, under the telnet protocol, using a process known as “login”. The login process involves establishing a logical connection between the first computer and the second computer. Generally, a login is carried out as follows. A user issues a login command to the first computer, and provides values for the following parameters: name of the second computer; name of a user account on the second computer; and a password associated with the user account. The first computer sends a login request, packaged according to the telnet protocol and containing the parameter values, to the second computer. The second computer authenticates the user account name and password. If they are valid and associated with one another, the second computer grants access to the first computer. The terminal interface of the second computer then becomes remotely available to the first computer, such that the user appears to be directly connected to the second computer.
If the first computer and second computer are communicating using a protocol such as RADIUS or TACACS+, without using telnet, the need may arise for either the first computer or the second computer to determine whether the other is still active and available over the logical connection. For example, the first computer may send a command to the second computer and not receive an acknowledgment from the second computer within a reasonable time. The first computer 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.
As another example, a system may be arranged to permit a predefined maximum number of connections between a client and server, or between a first server and a second server. A user, “fred”, may be entitled to establish a maximum of one connection from an access server associated with fred to a remote server. If the access server loses power or crashes, fred will not be able to dial in or establish a second connection because that connection would violate the allowed maximum. Thus, there is a need for a method that can enable the client to determine whether the access server is active.
Unfortunately, certain encrypted server-to-server communication languages or protocols, such as TACACS+ and RADIUS, provide no efficient way for a first server to know when a second server at the other logical end of the connection has gone offline. In this context, “offline” is used broadly to mean unavailable as a result of power failure, catastrophic system crash, transition to a degraded state, or disconnection of a logical or physical connection to a network. 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, and could thereafter terminate the session. Alternatively, the user could test whether the PC had stopped operating or crashed. In this context, a device is “off-line” when it is disconnected, crashed, or otherwise logically or physically unavailable.
When the first server communicates to the second server using an embedded protocol, however, there are no visual cues. The protocol is executed by the servers within a network, but such servers do not provide a visual display to the end user when they are in operation. Currently, the only way to know whether the client or access server has gone off-line or become unavailable is to use a timeout mechanism. In some telnet systems, timeout code will disconnect the access server and client after a pre-defined period of inactivity. This approach is a waste of system resources, however, because the access servers and/or outbound modems are occupied and unavailable during this period. Maintaining a TCP/IP connection for an Internet activity using the telnet protocol, for example, ties up buffer space and control sources in operating systems on both ends. Most systems have limited resources, and it is undesirable to leave open connections where there is no communication. Leaving an open telnet connection can also be a security breach
Calabrese John S.
Morris Herbert C.
Cisco Technology Inc.
Hickman Palermo & Truong & Becker LLP
Palermo Christopher J.
Tan Carina M.
Winder Patrice L.
LandOfFree
Detecting an active network node using a login attempt 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 a login attempt, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Detecting an active network node using a login attempt will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2949574