Electrical computers and digital processing systems: multicomput – Computer-to-computer direct memory accessing
Reexamination Certificate
1996-08-08
2002-06-18
Rinehart, Mark H. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer direct memory accessing
C709S241000, C709S227000, C709S241000
Reexamination Certificate
active
06408329
ABSTRACT:
BACKGROUND OF INVENTION
1. Field of the Invention
The invention relates in general to communications over computer networks, and more particularly, to remote login from one computer to another.
2. Description of the Related Art
The standard model for network applications is the client-server model. A server process is a process that waits to be contacted by a client process for which the server process performs some function. A typical scenario, for example, might involve a server process starting on some computer system in a network. The server process initiallzes itself, then goes to sleep waiting for a client process to contact it requesting some service. A client process is started on another computer connected to the server computer by the network. The client process sends a request across the network to the server requesting some form of service. The server responds by performing the requested service such as: print a file for the client, read or write a file on the server system and deliver it to the client, execute a command for the client on the server system, or allow the client to login to the server system.
The last mentioned function, allowing a user of a client system to login to the server system, can permit a user to enter instructions to the client and have those instructions executed by a server system. In this manner, it is possible for the user to access information stored in by server system or to utilize the processing power of the server system, for example. A login process ordinarily involves setting up a network connection between a client system and a server system. Establishing a network connection such that a client can issue instructions to a server system typically involves the creation of processes in both the client system and the server system to support the transfer of information, either instructions or data, between the two systems in such a fashion that instructions issued by a user, through the client system control the server system, and so that data provided by the server system is displayed by the client system.
In a UNIX operating system environment, one of the most common approaches to login to a remote system is through the well known “rlogin” (remote login) process. A description of the popular rlogin process is provided in
Unix Network Programming
, W. Richard Stevens,. Prentice Hall, Inc., 1990, chapter 15, Remote Login, pages 589-667. An exemplary implementation of rlogin will be explained with reference to
FIGS. 1A
,
1
B and
1
C.
FIG. 1A
illustrates the structure and interaction among client side process modules prior to the execution of the rlogin process.
FIG. 1B
illustrates the structure and interaction among client side process modules following the execution of the rlogin process.
FIG. 1C
illustrates the structure and interaction among server side process modules following the execution of the rlogin process.
Referring to
FIG. 1A
, before rlogin is invoked, a user communicates directly with the client system through a shell program
20
created in user memory space. The shell program is a command interpreter that users typically execute after logging into the client system. In essence, the shell program receives user input and acts on it. The shell program, for example, may respond to user input by issuing calls to appropriate operating system services that exist in the system kernel memory space. For a general discussion of the UNIX operating system, refer to
The Design of the UNIX Operating System
, Maurice J. Bach, Prentice -Hall, Inc., 1986. The shell program is discussed at pages 6-15 of that book.
In the UNIX operating system environment, user memory space and kernel memory space ordinarily are separated. Generally, although user memory space ordinarily is occupied by user processes and files, it may be preempted by the kernel. Kernel memory space usually can be occupied only by the operating system kernel unless the kernel gives up the space. As a result, special operating system communications mechanisms have been developed to transfer information (data or instructions) across the user-kernel memory space boundaries. One such mechanism involves “streams”. In
FIG. 1A
, a stream-head transfers information between a tty-connection module
24
, in kernel space, and the shell program
20
, in user space.
A tty-connection allows a process to communicate with an external device such as disks, tape drives, terminals and networks. The kernel modules that control devices are known as device drivers. Terminal drivers have the same function as other drivers: to control the transmission of data to and from terminals. Terminals are the user's interface to the system. Examples of terminal devices include, keyboard, mouse and display screen. To accommodate interactive use of the UNX system, terminal drivers typically contain an internal interface to line discipline modules, which interpret input and output. For example, in canonical mode, the line discipline converts raw data sequences typed at the keyboard to a canonical form before sending the information to the receiving process. The line discipline also converts raw output data produced by processes into a form the user expects. In raw mode, the line discipline passes data between processes and the terminal without such conversions.
In operation, tty-drivers
26
, responsive to user input strokes on a keyboard, for example, communicate with the tty-connection module
24
, which in turn, communicates through the stream-head
22
with the shell program
20
. The terminal-connection, for example, can be a stack comprising multiple modules that have been individually pushed onto the stream beneath the stream-head
22
. The shell
20
interprets the user keyboard input and issues appropriate system calls.
A description of streams in a UNIX operating system environment is provided in,
Unix Network Programming
, Sections 7.7-7.9, Pages 374-386. A stream is a full-duplex connection between a user process and a device driver or a pseudo-device driver. A typical stream connection includes a set of linearly linked queue pairs, one member of each pair for input and the other for output. The top portion of a stream in the kernel space is referred to as a stream-head and serves as a system call interface. A feature of streams is that a process can add modules between the stream-head and a device driver or pseudo-device driver. Each new processing module is pushed onto the stream just below the stream-head in a LIFO stack. An example of a stream process module is one that implements terminal line discipline. Another example of the use of stream modules is to implement a communication protocol. For example, a device driver may serve as a network interface (Ethernet device driver, token ring device driver, etc.), and a series of linked stream modules may provide a layered network protocol (TCP/IP, XNS, etc.) When a process writes data to a stream, the kernel sends the data down the stream's output queue. When a device driver receives input data, it sends the data up the stream's input queue to a reading process. The stream modules operate on the data as the data is passed up and down the stream queues.
Referring to
FIG. 1B
, when rlogin is invoked, it instantiates a set of software modules that interact to cause the client system to implement a remote login to a server system. More particularly, a client side network-connection
28
is created, in kernel space on the client system, to the server system. The client side network-connection
28
(within dashed lines) communicates with TCP-lower-q
31
(“transport control protocol”) and is linked to a new stream-head
32
. The network-connection
28
, for example, may include a TCP-upper-q module
27
and a sockmod
29
(“socket connection”). The TCP-upper-q
27
transfers information to and from TCP-lower-q
31
over the network that connects the client and server systems. The current tty-connection state is saved, and the tty-connection is set to the raw mode. An rlogin-r client process
34
is created in user space
Cass Nathan
Rinehart Mark H.
Starr Mark T.
Unisys Corporation
Vu Thong
LandOfFree
Remote login does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Remote login, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Remote login will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2947669