Geographically distributed multiprocessor time-shared communication processing system

Abstract

A geographically distributed multiprocessor system is implemented by locating groups of processors at nodes which are interconnected by way of a transport network and which are connected by way of local lines to customer terminals and hosts. Each processor supports a plurality of processes including certain process executing programs "customized" for the customers and other processes executing programs having "universal capabilities" which serve common needs of a plurality of customers. Processes communicate with other processes in the same processor by way of internal links and with other processes in other processors by way of combinations of internal links and external communication links. Interface processes exchange data between the internal and external links. A process can initiate a call to any other process and define the communication parameters for exchanging data information by selecting the appropriate internal link and supplying the code defining the communication parameters to the selected internal link.

Claims

What is claimed is:

1. In a multiprocessor communication processing system for use in a communication or telephone network wherein in said system each processor supports a plurality of processes,

a communication system having communication connections between processes for transferring data in accordance with communication parameters, and

means invoked by each process requesting a connection to the other processes in the same and different processors for selecting a connection therebetween and passing data defining communication parameters to the selected connection,

at least a portion of the communication parameter data being defined by the means invoked by the requesting process independent of the requesting process program code and at least a portion of the communication parameter data being supplied to the means invoked by the requesting process by means responsive to program code being executed by the requesting process.

2. In a multiprocessor communication processing system in accordance with claim 1 and further including:

means invoked by each of the other process in response to the selection of a connection thereto for processing the communication parameter data.

3. In a multiprocessor communication processing system in accordance with claim 1 wherein the means invoked by the requesting process includes means responsive to program code being executed by the requesting process.

4. In a multiprocessor communication processing system in accordance with claim 1 wherein the connections from each of the processes to other processes in the same processor are formed by internal links accessible to the processes and the connections from each of the processes to other processes in different processors are formed by combinations of the internal links and external communication links connected between each of the processors and the means invoked by the requesting process selects the internal link of the connection.

5. In a multiprocessor communication processing system in accordance with claim 4 wherein each of the processes are uniquely identified and the means invoked by the requesting process selects the internal link in accordance with the unique identification of the other process.

6. In a multiprocessor communication processing system in accordance with claim 5 wherein the connection formed by combinations of internal links and each external communication link includes an interface process for interchanging data between the external communication link and the internal links.

7. A multiprocessor communication processing system for use in a communication or telephone network, each processor supporting a plurality of processes, different ones of the processes supporting:

a process for manipulating data derived from various sources,

a process for managing data in response to the manipulated data,

a process for delivering managed data to a destination process,

the processing system further including:

a communication system having communication connections between processes for transferring data in accordance with communication parameters, and

means invoked by each process requesting connections to other processes in the same and different processors for selecting a connection therebetween and passing data defining communication parameters to the selected connection,

at least a portion of the communication parameter data being supplied to the means invoked by the requesting process by means responsive to program code being executed by the requesting process, and at least a portion of the communication parameter data being defined by the means invoked by the requesting process independent of the requesting process program code.

8. A multiprocessor communication processing system in accordance with claim 7 and further including:

means invoked by each of the other processes in response to the selection of a connection thereto for processing the communication parameter data.

9. A multiprocessor communication processing system in accordance with claim 7 wherein the means invoked by the requesting process includes means responsive to program code being executed by the requesting process.

10. A multiprocessor communication processing system in accordance with claim 7 wherein the connections from each of the processes to other processes in the same processor are formed by internal links accessible to the processes and the connections from each of the processes to other processes in different processors are formed by combinations of the internal links and external communication links connected between each of the processors and the means invoked by the requesting process selects the internal link of the connection.

11. A multiprocessor communication processing system in accordance with claim 10 wherein each of the processes are uniquely identified and the means invoked by the requesting process selects the internal link in accordance with the unique identification of the other process.

12. A multiprocessor communication processing system in accordance with claim 11 wherein the connection formed by combinations of internal links and each external communication link includes an interface process for interchanging data between the external communication link and the internal links.

13. In a multiprocessor communication processing system for use in a communication or telephone network

means invoked by terminating end processes responsive to calls thereto from originating end processes for reading parameter data on local links accessible to the terminating end processes and establishing communication with the originating end processes by way of such local links in accordance with parameters defined by the parameter data;

means for establishing data interchange between links local to different processors and for specifying ones of said parameters; and

means invoked by originating end processes initiating calls to terminating end processes for writing parameter data onto local links accessible to such terminating end processes when the terminating end processes are supported by the same processor and for writing parameter data onto local links that interchange data with links local to another processor when the terminating end processes are supported by such other processor.

14. In a multiprocessor communication processing system in accordance with claim 13 wherein the means invoked by the originating end processes includes means responsive to program codes being executed by the processes.

15. In a multiprocessor communication processing system in accordance with claim 13 wherein the means invoked by the terminating end processes includes means responsive to program codes being executed by the processes.

16. In a multiprocessor communication processing system in accordance with claim 13 wherein the means for establishing data interchange between internal links in different processors includes external links for interconnecting the processors and an interface process in each of the processors for interchanging data between the internal links of the processor and the external links.

17. In a multiprocessor communication processing system for use in a communication or telephone network wherein each processor supports a plurality of processes, a method invoked by an originating end point process for establishing data communication with a terminating end point process comprising the steps of:

identifying communication parameters supplied by the originating process for the data communication;

selecting one of a plurality of links internal to the processor supporting the originating process and extendible from the originating process toward the terminating process when the terminating process is in the same processor and extendible from the originating process toward an external link when the terminating process is in another processor;

passing data defining the identified communication parameters to the selected one of the internal links; and

exchanging data between the originating process and the selected internal link in accordance with the identified communication parameter and in accordance with communication parameters supplied by other than the originating process.

18. A method for establishing data communication in accordance with claim 17 wherein the step of identifying communication parameters includes the step of executing program code of the originating process.

19. A method for establishing data communication in accordance with claims 17 or 18 wherein the step of selecting an internal link includes the step of executing program code of the originating process.

20. A method for establishing data communication in accordance with claims 17 or 18 wherein the step of selecting an internal link includes the step of selecting an internal link which extends to a process, in the same processor, that interfaces the external link when the terminating process is in another processor.

Description

This application is filed concurrently with an application of G. R. Babecki et al, Ser. No. 393,138, (which issued as U.S. Pat. No. 4,500,960 on Feb. 19, 1985) which discloses similar subject matter.

TECHNICAL FIELD

This invention relates to integrated data processing and communications services and, more particularly, to a geographically distributed multiprocessor system for providing data processing and communications service.

BACKGROUND OF THE INVENTION

Recent rapid advances in the development of data processors and software implementations are making more and more data processing services available to users. Basic services, such as the processing and manipulation of data in response to instructions and commands and the managing of data including storing such data in records and files, modifying the stored data and reading the stored data are now within economic reach of both small and large users. Typically, the processing is provided by one or more digital computers cooperating with externally connected user devices, such as data terminals, which may provide the data to be manipulated, managed or transferred or the commands and instructions for the data.

Some "users" of data processing services may find it preferable to process data in their own, on-premises, host computer. A single such "user" may have widely geographically separate "subsidiary" locations (such as "outlets" for a manufacturer) and thus have need for processing services at these various locations. One solution is to send all raw data through the common carrier network to the "user" host and return processed data, as needed, to terminals at the "outlet locations". Another solution is to provide distributed processing services at or near the various terminal locations to reduce the carrier network communications between each terminal and the host computer. More specifically, in accordance with the latter solution, it is advantageous to provide local services such as editing of "text", interpretation of commands, creation of forms, accumulation and manipulation of numerical and text data and the like, at locations adjacent or near to the several terminals. The carrier network communication between the host and the terminals is then limited to data after such accumulation, manipulation and editing at the various locations. It has been suggested that the provision of such distributed processing services can be appropriately handled by a service vendor for a plurality user "customers", reducing the cost for each "customer" by time-sharing the usage of processing equipment among such plurality of "customers".

Since each customer has unique and differing processing needs, individualized programs, specially tailored for these needs, must be available for the several customers. It is therefore clear that each distributed processing location (or node) for the above-described service necessarily must accommodate a large number of programs (for a plurality of customers) and each node might preferably comprise a plurality of processors or CPUs, each processor supporting a plurality of programs. As is well known in the art, only one program can actually be "executing" at any given time in a computer. However, if the program currently running should terminate, time-out, or go into a "wait" state pending the occurrence of some "event", such as the completion of any input/output operation, another program is immediately available to begin executing, thus permitting different customer programs the opportunity to time-share computer time.

In discussing the execution of a program, it is important to understand the concept of "processing". A process is the total environment in which a program (or image) executes and has, in addition to the image, three further components, namely: (1) memory space allocated to the process for storing the image, for storing data generated and used by the image and for storing control information; (2) a software context which includes such pieces of information such as priorities and privileges allocated to the process, a unique process identifier, accounting information and so on; and (3) a hardware context which comprises the contents at any instant of time of the general purpose registers within the processor or CPU. Whenever execution of the process is suspended, its hardware context is stored in memory before another process begins execution. When a process is again allowed to execute, its hardware context is restored in the registers so that the process can resume execution at the point it was interrupted without again processing previously manipulated data or reexecuting commands or instructions.

As previously noted, each customer of a service vendor typically has needs and requirements that differ from, in part, and are similar to, in part, the needs and requirements of other customers. To satisfy these diverse customers, it is advantageous for the service vendor to create an individual process to execute each "customized" program developed for the unique needs of each customer and create other processes to execute programs having "universal capabilities" which satisfy common needs of a plurality of customers. A broad object of this invention is to provide an integrated distributed-processing system having both "customized" and "universal" processes.

A communication subsystem for transferring data between the several processes is a critical element in an integrated distributed-processing system suitable for diverse time-sharing customers or users. An important attribute in such a communication subsystem is to identify and select process-to-process connections in response to a request from an originating process to call a terminating end-point process. In addition, when calling via another system (such as the common carrier network), the subsystem should provide system-wide communication criteria or parameters, such as a maximum rate of data flow and a minimum grade of service. It is advantageous to offer users or customers "customized" processes that have at least partial control over the communication parameters, such as setting the data flow below the communication subsystem maximum rate of flow or setting a grade of service above the communication subsystem minimum grade of service, for example. It is therefore a further object of this invention to provide a communication subsystem for a distributed, time-shared, processing system which accommodates the diverse needs and requirements of the various processes.

SUMMARY OF THE INVENTION

In accordance with this invention, a communication subsystem is provided having communication connections between processes for transferring data in accordance with communication parameters and each process, when requesting a connection to another process, invokes the selection of a connection between the processes and invokes the passage of data defining communication parameters to the selected connection. In accordance with one aspect of this invention, the connection selection and the parameter data passage is invoked when a process requests connection to another process, whether in the same processor or in a different processor. As an additional feature, at least a portion of the communication parameter data is supplied by the requesting process and, more particularly, is supplied by program code being executed by the requesting process, whereby each requesting process has at least partial control of communications over the communication subsystem, thereby creating a communication subsystem that integrates diverse processes having differing communication requirements.

It is a feature of this invention that the connection selection and the data passage invoked by the requesting process comprises program code being executed by the requesting process to thereby enhance the partial control the requesting process has over the communication subsystem.

In accordance with a specific embodiment of this invention, described hereinafter, the several processors of the integrated communication processing system support processes for manipulating data derived from various sources (which process advantageously might constitute the application processes customized for the various customers and/or users), processes for managing data in response to manipulated data and processes for delivering managed data to one or more destination processes (which latter processes might constitute the "universal" processes that support the application processes). A connection from each of these processes to another process in the same processor is formed by internal links accessible to such processes. A connection from each of the processes to another process in a different processor is formed by a combination of external communication links connected between the processors and internal links accessible to interface processes which interchange the data between the internal and external links. As a consequence, when a process requests a connection to another process in the same or in another process, an internal link is always identified and the communication parameter data is passed to such internal link whether the other process is in the same or in a different processor. Accordingly, a universal and therefore a simplified connection setup and protocol procedure is provided to enhance integration of the multiprocessor system.

The foregoing and other objects and features of this invention will be more fully understood from the following description of an illustrative embodiment thereof taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 discloses, in schematic block form, a group of processors at one geographic location (hereinafter called a node) and the manner in which it is connected to customer terminals and hosts and to other nodes by way of a transport network to form an integrated data and communication processing system in accordance with this invention;

FIG. 2 depicts the details of the various equipments arranged to form a multiprocessor node in accordance with this invention;

FIGS. 3-8 constitute a flow diagram interconnected as depicted in the several Figures showing the general functions of the integrated data and communication processing system when following a specific scenario;

FIGS. 9-36 disclose a flow diagram of several processes providing the internal communication capability supported by each processor;

FIGS. 37 and 38 depict a flow diagram for an interprocessor interface process;

FIGS. 39-48 depict a flow diagram for a transport network interface process;

FIGS. 49-51 disclose a flow diagram for an access handler process;

FIGS. 52 and 53 show a flow diagram for a frontend processor interface process;

FIGS. 54-56 depict a flow diagram of several processes providing a data base service capability for the multiprocessor data and communication processing system;

FIGS. 57-61 depict a message application process which might advantageously be a customized process available to a specific customer or user; and

FIGS. 62-78 disclose flow diagrams of various processes providing a store and forward service capability for the multiprocessor data and communication processing system.

DETAILED DESCRIPTION

System Architecture

A system for providing communication processing services is shown in FIG. 1. In general, the system consists of a plurality of nodes, such as node 110, which nodes are connectable to, and are available for, providing services for data terminals and/or host computers which are symbolically represented in FIG. 1 by terminal or host 101 and are hereinafter individually referred to as terminal 101. Each of terminals 101 may access node 110 by way of a suitable transmission line, such as data line 104. In addition, each of nodes 110 is connectable to a transport network 80 which may comprise a common carrier communication system or, advantageously, a packet switching network for transporting data packets from node to node. The connection between each node 110 and transport network 80 preferably comprises digital line 105 and it is contemplated that node 110 communications over digital line 105 utilizing a data packet format. Accordingly, each terminal 101 has access to services in each node 110 connectable thereto and, in addition, each node 110 can access other nodes via transport network 80 to provide each terminal further services available in other ones of nodes 110, which further services may include capabilities to communicate with, and send messages to, terminals connectable to the other nodes.

The details of a typical node, such as node 110, is shown in FIG. 2. As noted with respect to FIG. 1, and as seen in FIG. 2, node 110 is connected to and communicates with the various terminals (and/or hosts), such as terminal 101, by way of digital data transmission lines, such as data line 104. In addition, node 110 is connectable to a transport network 80, which connection may be effected by way of digital line 105.

Hardware units in node 110 advantageously include a plurality of computer processors, such as node processors 107 and 113, and a data base processor, such as data base processor 108, all interconnected by way of data bus 112. A suitable processor to implement these processors described above is the VAX 11/780 machine manufactured by Digital Equipment Corporation of Maynard, Mass., supplemented by the VMS software operating system offered by Digital Equipment Corporation. The VAX computer and the VMS operating system are described in VAX 11/780 Architecture Handbook, VAX 11/780 Hardware Handbook and VAX 11/780 Software Handbook, all published by Digital Equipment Corporation.

In node 110, sets or groups of the data lines 104 terminate in microprocessors, such as microprocessor 102 wherein each microprocessor 102 is arranged to communicate with each terminal 101 connected to the other end of each data line 104. A suitable microprocessor is the PCS microprocessor manufactured by International Business Machines Corporation of Rochester, N.Y., and described in U.S. Pat. No. 4,188,665 issued to D. M. Nagel et al on Feb. 12, 1980. Each PCS microprocessor 102, in turn, is connected to front-end processor 103. It is a principal function of PCS microprocessor 102 to receive and recover data from each data line 104 and originated by the terminal connected thereto, such as terminal 101, assemble such data into a byte format (which identifies such data line) and forward the bytes to FEP 103. In the reverse direction data bytes (identifying such data line) are received from FEP 103, are formatted into a data bit stream format (appropriate for a data line) and are selectively directed over such identified data line 104 to terminal 101.

Each front-end processor, such as FEP 103, communicates with node processor 107 (or node processor 113) by way of a communication link, such as X.25 link 106. It is broadly the function of FEP 103 to receive the data bytes from PCS 102, to assemble the bytes into blocks of data, to process and to packetize such data blocks in a manner described in detail hereinafter and to direct the data packets over data link 106 to node processor 107 via microprocessor 115. In the reverse direction data packets from node processor 107, directed to terminal 101, are passed through microprocessor 115 and over link 106 to FEP 103 which depacketizes the data into blocks, processes the blocks, assembles them into data bytes and sends the data bytes to PCS 102 for conveyance to terminal 101 via data line 104. A suitable processor to implement front-end processor 103 comprises the Series/1 minicomputer manufactured by International Business Machines Corp. Front-end processor 103 is supplemented by the RPS software operating system 118 offered by International Business Machines Corp. The Series/1 minicomputer and the RPS software operating system are described in Series/1 Digest, Fourth Edition (1979) published by International Business Machines Corp.

FEP 103 is further provided with various software programs, routines and tasks to provide the above-described and other functions. For example, Extended Execution Support (EES) System 121 is a software system that supplements the RPS operating system of FEP 103, which combination assembles data bytes received from PCS 102 into data blocks and, in the reverse direction, disassembles blocks into corresponding data bytes for transmission to PCS 102. X.25 routine 122 constitutes a software routine package or system that supplements the RPS operating system. Functions performed on outgoing data include link layer protocol consistent with standard X.25 level 2 protocol and packet level functions to packetize the data blocks and pass such packets by way of a "virtual" channel reserved for the terminal over X.25 link 106 to node processor 107. In the reverse direction X.25 routine 122 provides the packet level functions to assemble data packets on each channel on line 106 from node processor 107 and form them into corresponding data blocks and present the depacketized data blocks to various software tasks and routines in FEP 103 and, in addition, performs the link layer (X. 25) protocol functions. The protocol and formatting provided by X.25 routine 122 is further described in Data Communications Standards, Edition II, Copyright 1982, McGraw-Hill Publication Co., New York, and more specifically described in "Part 1, International Telegraph and Telephone Consultative Committee (CCITT) Data Communication Recommendations". EES system 121 is a software product offered by the International Business Machines Corp. and further described in Series/1 Digest disclosed above.

The RPS operating system 118 of FEP 103 is further supplemented, in accordance with this specific embodiment of this invention, by Access Handler Process (AHP) software task 120. An AHP task 120 is provided in FEP 103 for each of the data lines, such as data line 104. For the present description, it is assumed that data line 104 extends to only one terminal, such as terminal 101, and that therefore AHP 120 need only accommodate a single terminal. It is apparent, however, that data line 104 may comprise a multipoint line and extend to a plurality of Terminals and AHP 120 would therefore accommodate a plurality of terminals.

It is a principal function of each AHP task 120 to control the processing of data blocks assembled by EES 121 (from data bytes received from PCS 102), such processing including inserting the network standard address (NSA) of the associated terminal 101 in the data block. As explained hereinafter, with the NSA inserted in the data block, data from the terminal is invariably conveyed by way of a reserved "virtual" channel over line 106 to processor 107. It is a further function of each AHP 120 to select the data in the reverse direction on the reserved channel over link 106 from node processor 107, correspondingly inserting the NSA of the terminal in the data block. Thus, the terminal on the data line associated with the AHP 20 task is interconnected with its corresponding "virtual" two-way channel which extends to node processor 107.

The interconnection to node processor 107 over link 106 is provided by way of processor 115. Processor 115 advantageously constitutes a microprocessor arranged to provide the link layer or level 2 (X.25) protocol interchange with X.25 routine 122 in FEP 103. Accordingly, microprocessor 115 functions in substantially the same way as the link layer protocol functions in X.25 routine 122. A microprocessor suitable for use for implementing microprocessor 115 and providing the above-described functions is the KMS microprocessor manufactured by Digital Equipment Corp. and described in "KMD11-D Reference Manual, KMC11-B X.25 Protocol (LAP and LAP-B) Level 2 Firmware", Doc. No. YP-A33YA-00; "KMC11 General Purpose Microprocessor User's Manual", Doc. No. EK-KMC11-OP-PRE; and "VAX/VMS KMD11-D I/O Driver User's Manual", Doc. No. YM-T041C-VO, all published by Digital Equipment Corp.

Node processor 107 has various capabilities, such as communicating with the "virtual" two-way channels, accepting and interpreting various commands and requests from the channels, extending calls to other processors in node 110 and in other nodes and carrying out such commands and requests, either solely or in cooperation with other processors. In addition, node processor 107 can call terminals connected to the processor or connected to other processors in node 110 and in other nodes, as described in further detail below. Various software processes in node processor 107 are utilized to supplement the VMS operating system to provide these capabilities, which processes include Application Control Process (ACP) 119, Front-End Processor Interface process (FEPI) 123, Message Application Process Interactive Session Package (MAP-ISP) 126, Interprocessor Interface Process (IPI) 128 and Transport Network Interface process (TNI) 134. Although node processor 107 advantageously is implemented with other software processes, the description thereof is directed to the above-identified processes to fully describe the invention, a description of such other software processes being not necessary for an understanding of the invention.

Each node processor 107 accommodates one or more Front-End Processor Interface processes, each such process terminating an individual link 106 (connected to the interface process via KMS 115). Front-End Processor Interface process 123 initiates, terminates and manages connections between each of terminals 101 (via channels on the connected link 106) and other ones of terminals 101 connected to the same or other processors and connections between the terminals 101 and application processes (such as MAP-ISP 126) in node processor 107 or in other node processors (in node 110 or in other nodes). More specifically, FEPI 123 creates, manages and terminates two-way communication paths to enable terminal 101 to communicate with an application process or a remote terminal and to enable an application process or a remote terminal to communicate with terminal 101. Elements of FEPI 123 involved in these functions include Interface Routine 124, a portion of Internal Communication (IC) Subsystem 136 which is depicted in FIG. 2 as part of FEPI 123 and Station Call Facility (SCF) tasks 125.

Interface Routine 124 disassembles the incoming data packets from microprocessor 115 on each channel on link 106 (from FEP 103) and forms them into blocks of data, hereinafter called information units (IU). Each IU is passed to an SCF 125 task which is individual to the channel (and is therefor individual to one of the terminals). In the reverse direction, each IU from an individual SCF 125 is assembled into data packets by Interface Routine 125 and the data packets are passed via microprocessor 115 to the channel on link 106 corresponding to the individual SCF 125 and thus are destined for the associated terminal.

One of the principal capabilities of SCF task 125 is to extend (two-way) calls (from the individual terminal 101) to various application processes in node processor 107 or in other processors in the same or other nodes. Another SCF task 125 capability is to extend calls to other Station Call Facility tasks in the same or other FEPI 123 processes in node processor 107, in node processor 113 or in a processor in another node. Alternatively, other SCF tasks and application processes may extend a two-way call to SCF task 125, thus providing the capability of extending a call to the terminal associated with SCF task 125. SCF task 125 also has the capability of taking down (disconnecting) any of the above-mentioned calls or connections.

A request by a terminal user to run an application program (such as a program in MAP-ISP 126) may advantageously be first forwarded by SCF task 125 in FEPI 123 to the Application Control Process (ACP) 119. ACP 119 initially determines whether the particular terminal user is authorized to access the application program in question and assuming that the user has such authorization determines whether a process containing the application program presently exists in the node processor. In the event that the program does not exist, ACP 119 calls the VMS operating system to create the application process (such as MAP-ISP process 126) that will contain the program the user desires to run. ACP 119, upon determining that the process is already in existence or alternatively upon determining that the process has been created, redirects the call to the application process thus forming a two-way call (or virtual connection) between SCF task 125 and the application process and permitting communication between such process and the associated terminal user. A more detailed description of a suitable application control process and a method of creating, initializing, scheduling and executing processes (including application processes ) are disclosed in further detail in D. A. Zave Case 1 Ser. No. 393,123, filed June 28, 1982.

In addition to the above-described connections, processes in the same processor, in general, may create similar two-way (virtual) connections between them. The formation of virtual connections between end-point user processes is provided by a capability called an Interprocess Communication (IC) Subsystem. In this embodiment, the IC Subsystem is distributed in and constitutes a portion of the several end-point user processes, such user processes including ACP 119, FEPI 123 and MAP-ISP 126, wherein the Subsystem portion is identified as IC Subsystem 136. (It is noted that the IC Subsystem is also distributed in other processors and thus included in Store and Forward Transfer (S&FT) process 132, Store and Forward Delivery (S&FD) process 131, Data Base Server process 130 and Data Base Work Manager process 131 in data base processor 108).

Each IC Subsystem 136 in each user process is substantially identical to the IC Subsystem 136 in each other user process. Capabilities of each IC Subsystem 136 in each user process include forming a virtual two-way connection (or intraprocessor link) with an IC Subsystem portion in another user process in the same processor, writing data information units (IUs) into and reading data from the formed connection, exchanging housekeeping and protocol information with the other IC Subsystem portion and disconnecting the formed connection.

Each process is provided with a unique systemwide identity or address called a Network Standard Address (NSA). When a process initiates a call to another process, it specifies to its IC Subsystem 136 the NSA of this other terminating end-point process. As discussed hereinafter, this provides the capability of forming a virtual two-way connection with any other process in any other processor in the system, utilizing these same capabilities of IC Subsystem 136. Certain of the processes, such as those processes providing application functions for "customers" or terminal users, may also require certain communication parameters, such as control of the data flow rate or "affirmative" data delivery assurance. IC Subsystem 136 provides three layers of communication control for routing, redirecting and disconnecting calls and for passing and controlling outgoing and incoming data between the end-point processes through the formed connection. More specifically, outgoing commands, such as call requests and data from the user process, are first passed to a "session layer" in IC Subsystem 136. The "session layer" supports the interface to the user process, checks the arguments directed to the formation and control of the interconnection and provides assurance that the data is passed through the connection (or formed) in accordance with the communication protocols defined by the user. The commands and data are then passed to a "transport layer" that specifies system-defined and end-to-end service, such as generating sequence numbers and defining flow contol information. It is to be noted that both the user process and the system may define their own flow control information in accordance with the needs of each, in which case, the system requirements prevail unless the user process requires a flow slower than the system requirement.

After passing through the "transport layer", the commands and data are passed to a "network layer" which refers to a system routing table to select or identify a specific connection (or intraprocessor link) to another end-point process which, as noted above, is identified by is NSA. (It is noted here that for calls to processes in other processors, the intraprocessor link to a process interfacing an appropriate external communication link will be selected.) The "network layer" also moves the data to the intraprocessor link thus identified.

Incoming commands and data to the IC Subsystem of any user process is first passed through the "network layer" which moves the commands and data from the connection and then through the "transport layer" which provides the corresponding "system" end-to-end services as the outgoing side and then finally through the "session layer" which supports the interface to the process receiving the data. Accordingly by virtue of IC Subsystem 136, a user process (which includes such a subsystem) can complete a connection to another user process in the same processor and exchange, on a two-way basis, necessary control and protocol information for both the user processes and the system communication "network" together with any data that the processes desire to interchange.

A process in one processor (such as MAP-ISP 126 in node processor 107) can call a process in another processor (such as Data Base Work Manager process (DBWM) 131 in data base processor 108). The virtual connection created by this call is extended through IPI 128 in node processor 107, data bus 112 and IPI 129 in data base processor 129. As described in detail hereinafter, IPI 128 and IPI 129 provide interfaces with data bus 112 to form connections and to pass IUs between the two processes. IPI 128 and IPI 129 are provided with interprocess communication subsystem capabilities (depicted as IC 142) which are substantially identical to the corresponding IC capabilities that IC Subsystem 136 provides for its user processes. Accordingly, any user process in any node processor, such as node processor 107, may connect to and exchange data with a data bus interface process (such as IPI 128) in the same manner as the user process connects with and communicates with another user process in the same processor. Thus, for example, a user process may desire to communicate with IPI 128 for purposes such as monitoring or testing portions of the process.

In addition to the above-described interprocess communication capability, each data bus interface process is arranged to forward a call from a user process in the same processor to a process in another processor by way of data bus 112. In this case, the "network" layer of the IC Subsystem of the calling process (when referring to the routing table and utilizing the NSA of the remote process) selects or identifies an internal link to the interface process. The "network layer" of IC Subsystem 142 of the data bus interface process is then arranged to move incoming commands and data from the connection and then transfer such incoming commands and data to a channel on data bus 112 without the commands and data passing through the "transport" and "session" layers. In the other direction, incoming calls and data from data bus 112 are read by IC Subsystem 142 of IPI 128 and then transferred directly to the "network layer" of IC Subsystem 142. The network layer, in response to an incoming call from the data bus, refers to the routing table to identify the next link to the called end-point processor. The call is thus extended and data is thereafter moved to this final link in the connection with the terminating end-point user process without passing through the transport and session layers of the IC Subsystem of IPI 128. IC Subsystem 142 of IPI 129 correspondingly extends calls and transfers incoming data from processes in data base processor 108 directly from its "network layer" to data bus 112 and in the reverse direction extends calls and transfers data from data bus 112 to the outgoing "network layer" without passing through the "transport" and "session" layers. Accordingly, when a call is made and when a connection is formed between an end-point user process in one processor, such as processor 107, to an end-point user process in another processor, such as processor 108, the "session" and "transport" layers of the IC Subsystem of each such end-point user process "communicates" with the "transport" and "session" layers of the other end-point user process without intervention of the "transport" and "session" layers of the bus interface processes. The "network" layer protocol for defining the route and moving the data into and out of the connection are exchanged, however, between each end-point user process and the corresponding bus interface process in the same processor. Consequently, with respect to forming interprocessor connections, the two end-point user processes in different processors exchange protocol information (in part) at the "session" and "transport" layer levels in the same manner as though they are in the same processor.

An end-point user process (such as S&FT 132) can call an end-point user process in a processor in another node. The virtual connection created by this call is extended through IPI 129, data bus 112, IPI 128 and TNI 134 in node processor 107 and then via KMS 116 and transport network 80 to the other node and then through KMS 116 and TNI 134 in processor 107 in the other node to the appropriate process. KMS 116 constitutes a microprocessor which is substantially identical to KMS 115 and functions to provide the link level or level 2 (X.25) protocol interchange with the corresponding KMS 116 in the remote node. TNI provides the node processor interface with KMS 116 (and the transport network) and assembles IUs into packets for passage to the transport network and, in the reverse direction, depacketizes the data and reforms it into IUs. IC Subsystem 144 in TNI 134 is otherwise arranged in substantially the same manner as IC Subsystem 142 in the bus interface process, providing the three protocol layers when TNI 134 is an end user process and "bypassing" the transport and session layers when TNI 134 is an intermediate (or interface) process for a connection between processes in different nodes. Consequently, the two end user processes in different nodes can exchange information (via interface processes) in the same manner as though they are in the same processor.

Node processor 107 (and corresponding node processor 113) advantageously service a plurality of application processes; one of such processes, namely, MAP-ISP 126, being depicted in node processor 107. MAP-ISP 126 is arranged to interpret commands and transactions from terminals, such as terminal 101, carry out such commands, call other processes to assist in carrying out such commands or transactions, interpret commands or transactions received from other processes and forward such commands or transactions to terminals, such as terminal 101. It is noted that MAP-ISP 126 also includes IC Subsystem 136 whereby the process may extend calls to or receive calls from other processes. For example, calls from a Station Call Facility 125 in FEPI 123 may be extended to MAP-ISP 126 to form a two-way connection with an associated terminal 101 to receive the above-noted commands and transactions.

Two processes which are arranged to assist MAP-ISP 126 in carrying out commands constitutes Data Base Work Manager (DBWM) process 131 and Data Base Server (DBS) process 130. Data base processor 108 includes a plurality of DBS 130 processes and a single DBWM 131 process. These processes in combination with a suitable data base management system and disc files, such as disc 109, constituting data base service capability. DBWM 131, in response to a call for such service, assigns a data base service, such as DBS 130. DBS 130 is generally arranged to open a data base storage area, open a data base file, write information into, read information out of or modify such open file, close such file and close the data base storage area. A data base management system suitable for use in this arrangement is described in Communications of the ACM, Vol. 17, No. 10, "A Back-End Computer for Data Base Management", by R. H. Canaday, R. D. Harrison, E. L. Ivie, J. L. Ryder and L. A. Wehr, October 1974, pp. 575-582. Advantageously, one such data base management system known as SEED is offered by International Data Base Systems, Inc., Philadelphia, PA., and described in SEED User Manual, published by International Data Base Systems, Inc., Copyright 1981.

Other processes which are capable of assisting MAP-ISP 126 in carrying out commands and in communicating transactions are store and forward delivery (S&FD) process 131 and store and forward transfer (S&FT) process 132 (both in data base processor 108). S&FT 132 is capable of processing and transferring data messages on a store and forward basis. More specifically, S&FT 132 assembles store and forward messages and headers thereof and transfers these to S&FD process 131 if the message is destined for a process in the same node or, alternatively, transfers the message to a S&FT 132 process in another node if the message is destined for such remote node. S&FD 131 delivers the message to the appropriate destination process or processes (in its local node) as defined by addresses in the message header and parameters such as earliest delivery time.

General Operation

FIGS. 3-8 depict a work flow (flow diagram) of generalized functions that occur within and are provided by the several nodes 110 during the course of one of a number of scenarios that can be accommodated by the communication processing system. The general functions shown in the work flow and described hereafter are advantageously implemented by various processes which, when assembled into data code in the form of routines, tasks, et cetera, and invoked by a processing unit in node 110, provide the broad functions described hereinafter.

In the scenario described hereinafter, a terminal user (at terminal 101) turns on the terminal (goes on-line) and receives a prompt from the system requesting an address (of a process) to be called. The user sends the address of the MAP-ISP application process and the application process returns a prompt and awaits a command from the user. The terminal user then requests that text and header data be retrieved from the user's files in data base processor 108, that such header and text information be assembled into a message and that the assembled message be delivered on a store and forward basis to a locally and/or remotely located process or processes identified in the header. More particularly, in response to the "address" prompt, the terminal user calls the application process (which application process is advntageously MAP-ISP process 126) by sending a "connect" command containing the network standard address (NSA) of the application process. Upon being connected to MAP-ISP 126 and receiving the prompt from this application process, the terminal user sends a "send" command containing the appropriate instructions for retrieving the header and text data from the user's files, for forwarding the assembling message on a store and forward basis and for delivering the message to destination processes defined by NSAs (which, in this case, are contained in the header file).

When the terminal user turns on terminal 101, the resultant on-line condition (or code) is forwarded through PCS 102 to FEP 103. EES 121 assembles the signals with a data block which is passed to the AHP 120 task reserved for the terminal line. AHP 120, as depicted in step 200, detects this on-line condition and determines that the associated terminal 101 has just been turned on. AHP 120 in function step 201 passes this on-line condition code (in data block form) to X.25 routine 122 which packetizes the data and provides the necessary X.25 protocol. The packet then passes over the channel individual to the terminal on link 106 to microprocessor 115 which, as previously described, provides the appropriate protocol interchange. The data is then depacketized and formed into an information unit by interface routine 124 and the information unit (now designating the on-line condition) is forwarded on to the Station Call Facility 125 associated with the terminal. General function step 202 depicts the reception of the on-line condition by SCF 125 advancing the system processing step to decision 203, wherein SCF 125 checks whether the terminal is authorized to make fixed or variable calls.

If the terminal station is authorized to make fixed calls, decision 203 advances the overall system operation to function step 209. Alternatively, if the terminal station is authorized to make variable calls, decision 203 advances the system process to function step 204 wherein Station Call Facility 125 generates a prompt. This prompt is then returned by way of link 106 (that previously carried the on-line condition) and is passed to the AHP 120 task individual to the terminal data line. AHP 120 forwards this prompt back to the terminal line 104 by way of microprocessor 102 for display at the station.

As noted above, the terminal user in response to the prompt (from SCF 125), returns a "connect" command to extend the call to MAP-ISP 126, inserting in the command the NSA of the application process. This command is returned to AHP 120 and the task, as depicted in function step 206, provides the appropriate processing of the command and forwards the command (with the application process NSA) over the previously described channel to SCF 125. SCF 125 receives this variable call (NSA) address, as shown in function step 208. The sequential functions of the communication processing system thereupon advances to general function step 209.

In general function step 209, SCF 125 calls MAP-ISP 126, initiating the call by issuing a "connect" request to the IC Subsystem 136 (in FEPI 123) and designating the NSA of MAP-ISP 126 in the request. IC Subsystem 136 thereupon attempts to route the connection to the application process. In accordance with a preferred embodiment of this present system, to connect to an application process, the connection must first be extended to Application Control Process (ACP) 119. As described in detail in the above-noted application of D. A. Zave and as depicted in function step 212, ACP 119 initially conducts termination screening to determine whether the particular terminal (user) is authorized to access the application program. Assuming that the terminal user does not have such authorization, decision 214 advances the general system operation to function step 215. In function step 215, ACP 119 refuses the connection setup by returning an "abort" back through IC Subsystem 136. This abort is passed back to SCF 125, as depicted in function step 216, terminating the connection to ACP 119. SCF 125, in accordance with function step 217, generates a response for transmission back to the terminal user specifying that the connection has been refused due to lack of authorization.

Assuming now that the terminal user has authorization to run the program, decision 214 advances the system operation to decision 213. As described in the D. A. Zave application, ACP 119 now determines whether the desired program presently exists in node processor 107. Assuming that the application process presently exists, the operation advances directly to general function step 211. Alternatively, if the program is not presently in existence, ACP 119 creates a program image, as depicted in function step 218 and as described in detail in the D. A. Zave application. The control environment for the program image being created is at this time initialized, as depicted in function step 219, and the general system operation advances to function step 211. In function step 216, ACP 119 issues a command to IC Subsystem 136 to "redirect" the connection setup to MAP-ISP 126. This effectively completes the connection from SCF 125 to MAP-ISP 126 by way of the IC Subsystems in FEPI 123 and in MAP-ISP 126.

Although the particular mode of operation described above is contemplated by the inventors, it is of course realized that a process such as MAP-ISP 126 may also be directly accessed by SCF 125 by way of IC Subsystem 136 without the intervention of ACP 119 if termination screening and process creation is not desired or required.

When the program image in MAP-ISP 126 was created, it issues a "listen" request to IC Subsystem 136 to indicate that it is prepared to answer an incoming call. With the connection now redirected to MAP-ISP 126, IC Subsystem 136 thereupon informs the program image of this incoming call from SCF 125 as seen in function step 222. The call is thereupon accepted by the program image, the acceptance being indicated by the issuance of an "accept" request to IC Subsystem 136 as shown in function step 223. The acceptance provided by the program image is thus passed through IC Subsystem 136 and in accordance with function step 224 this acceptance is sent back to SCF 125. This completes the connection between SCF 125 and MAP-ISP 126 by way of the IC Subsystems of the two processes as indicated by function step 225 and with the connection completed MAP-ISP 126 sends a prompt back through the IC Subsystem in accordance with function step 226. Function 227 indicates the reception of the prompt by AHP 120 and this task then forwards the prompt back to the terminal user.

The above-described connection having been made and MAP-ISP having returned the prompt, the terminal 101 user transmits the "send" command (requesting that the message be transferred to a designated process or processes on a store and forward basis) to node 110 via line 104. The next function occurring in node 110, as symbolically identified by function step 231, constitutes the entering of the "send" command in Front-End Processor 103. This is accomplished by microprocessor 102 which communicates with terminal 101 over line 104 and EES routine 121 (in FEP 103) which assembles the command into a data block. The command data block is then passed to the Access Handler Processor 120 associated with the terminal line, as symbolically depicted by function step 232. Access Handler Process 120 inserts the network standard address (NSA) of the terminal, optionally provides code and format conversion, if desired, and buffers the converted character data block for subsequent transmission to node processor 107. The Access Handler Process (AHP) 120, as shown by function step 233, thereafter sends the buffered data block to node processor 107 by way of link 106 utilizing X.25 interface routine 122. As depicted by function step 234, X.25 interface routine 122 packetizes the data and sends the packets, utilizing the standard X.25 protocol, via the appropriate channel on link 106.

On the other side of link 106, KMS microprocessor 115 exchanges the standard protocol with routine 122 and the incoming data is depacketized and assembled into information units (IUs) by interface routine 124, as shown by function step 235.

In function step 236, as described in greater detail hereinafter, the Front-End Processor Interface process 123 routes the IU (which is the above-described "send" command) to the Station Call Facility task 125 which was previously reserved for the terminal. In function step 237, as described in further detail hereinafter, Station Call Facility task 125 "writes" the IU into the IC Subsystem connection previously formed between Station Call Facility task 125 and the Message Application Package Interactive Session Program (MAP-ISP) 126. Accordingly, the information unit is transferred by IC Subsystem 136 of FEPI 123 and MAP-ISP 126, utilizing a multilayer protocol (described hereinafter), which transfer function is depicted as function step 238.

It is presumed, at this time, that MAP-ISP 126 performs function step 239 which, as described in detail hereinafter, constitutes a request that an information unit in the connection be read into its (MAP-ISP) working or buffer area. Function step 240 is thereupon performed wherein the IU is read from IC Subsystem 136 into such work area of MAP-ISP 126.

When the information unit is read into the working area of MAP-ISP 126, the process provides function step 241, which function step involves invoking a parser routine to parse the "send command". Function 242 identifies the operation of the parser routine, parsing the "send" command data string. As described in further detail, this parsing involves composing a data structure for accommodating the command name and arguments for the specific "send" command. MAP-ISP 126 thereupon recognizes this command name in function step 243. The process then selects and initiates function step 244 to invoke a data base read system service which is implemented, in part, as noted above by DBWM 131 and DBS 130. As an initial step of such service, function 245 is invoked to open a file identified in the "send" command (the data base storage area of the user or customer being priorly opened during initialization of the MAP-ISP process).

It is presumed that one or more files defining a message header, defining a message text and storing a mnemonic translation table were previously stored in disc 109 locations and that the file locations for the header and text were included in the "send" command. Accordingly, the first file opened by the data base service is the file containing the message header. Function step 246 of the data base service is then invoked to read out the file and pass the contents into the MAP-ISP 126 working area. Next, function step 247 of the data base service is invoked to close this file. Function 245 is now again invoked, followed by steps 246 and 247, to open a text file, read it out, and close the text file and this sequence is repeated until all text files are read out. If a mnemonic translation is required, function 245 is again invoked, followed by steps 246 and 247, to open the translator file, read it out, and close the file. In step 247, when all files are read out and there is no further need for data base service, the data base storage area is closed. This concludes the data base read service.

As is described in detail hereinafter, the data base read service system also utilizes IC Subsystem 136 in MAP-ISP 126, IC Subsystem 142 in Interprocessor Interface Process 128, Interprocessor Interface Process 129 and IC Subsystem 142 in data base processor 108, TDM bus 112 and IC Subsystem 136 in Data Base Work Manager 131 and Data Base Server 130 to intercommunicate the various requests, instructions and responses between the MAP-ISP 126 process and the DBWM 131 and DBS 130 processes. The data base read system service also utilizes DBWM 131 and DBS 130 to open the files, read out the contents of the files, close the files and close the storage area.

MAP-ISP 126, in accordance with function 248, invokes a store and forward "open" primitive (routine) to form a "connection" with the store and forward system service and then "writes" the header and text files read out of the data base to this connection. This invokes Store and Forward Transfer process (S&FT) 132 which thereupon provides function 249 that stores the header and text, now arranged as a message, in an internal storage area.

MAP-ISP 126, as depicted in function step 250, identifies the end of the transfer of the message to the Store and Forward Transfer process and issues a store and forward "close". MAP-ISP 126, upon closing the message, again becomes available to subsequent commands from the user, issuing a prompt to the user in step 254. When the user, not requiring further service, disconnects, MAP-ISP 126 "terminates".

S&FT 132, upon being issued the store and forward "close", provides function 251 to close the message and initiate a transfer mechanism. This includes determining the node locations of the ultimate destination process and processes. The Store and Forward Transfer process then advances to decision 152 to determine whether an ultimate destination or ultimate destinations are to remote nodes. In the event that at least one of the addressees of the store and forward message is in a remote node, decision 252 advances the transfer process to step 256. In step 256, a connect command is issued to the IC Subsystem of the Store and Forward Transfer process to extend the connection to the corresponding Store and Forward Transfer process in such remote node (or nodes). Upon the completion of such connection, the message is delivered to the remote Store and Forward Transfer process and the local store and forward process thereupon disconnects as depicted in function step 257. In function step 257, the remote Store and Forward Transfer process accepts the message and stores the header and text in an internal storage area. The remote Store and Forward Transfer process is therefore now in the same condition as the originating Store and Forward Transfer process and, in this case, the ultimate destination of the message therein is a process (or processes) in the node local to this remote Store and Forward Transfer process. This advances the system function to function step 259. Alternatively, if the store and forward message is destined to a process in the local node of the originating Store and Forward Transfer process, decision 252 advances the process directly to step 259. Thus, step 259 constitutes the function of the Store and Forward Transfer process (originating or remote) in transferring the message to the Store and Forward Delivery process 131 local to such transfer process. This step involves sending the message file name to S&FD 131 together with the local NSA or NSAs.

The Store and Forward Delivery process in step 260 creates an "item" for each local destination process that will receive the store and forward message. Each item includes information such as the ultimate destination for the message and other parameters such as delivery time for each ultimate destination. In step 261, the Store and Forward Delivery process determines such delivery time for each of the items and, in step 262 notification is sent to the destination process when such delivery time is reached. This notification constitutes a "connect" request forwarded to the IC Subsystem to extend the call to the destination process.

Since the destination process invariably constitutes an application process, the IC Subsystem routes the call to ACP 119 as depicted by step 263. In step 264, ACP 119 conducts the authorization screening and creates the program image and, in step 265, the MAP process is initialized and ACP 119 redirects the connection to connect Store and Forward Delivery process 131 to the created MAP application process. The MAP application process now "checks" for the presence of the message in the Store and Forward Transfer process as depicted in step 268. This includes a command returned to the Store and Forward Transfer process by way of the connection to send an information unit containing message header and/or text information. A message ticket (including all information necessary to handling the message and the message header and text) are thereby transferred from the Store and Forward Transfer process to an internal storage area of the MAP application process. After such delivery, the MAP process disconnects to terminate the connection and, in accordance with data instructions and header information, delivers the message, which delivery may be to a customer terminal identified by the message header and serviced by the MAP process or to data base files of such customer. Accordingly, the communication processing system has delivered the store and forward message to appropriate customer terminals and/or files in accordance with various parameters and addresses contained in instructions in the send command of the originating terminal user and in the header files designated by the terminal user and in the customer's profile stored in the node processor and obtained by MAP-ISP 126 during the program's creation and initialization.

Internal Communication

As discussed above, the capability of a process establishing connections with other processes is implemented by an Internal Communication (IC) Subsystem. This subsystem is part of each end-point process and, when a connection between two end-point processes is formed, the IC Subsystem portion of each end-point process provides the session, transport and network layer functions for the process, as described in detail below. It is noted that the IC Subsystem is also part of interface processes for use when the interface process is an end point. When the interface process is not an end point and used as an interface to connect another process to an external link, the network layer only is utilized.

In order to establish a connection, the calling process issues a call to an IPC-Connect routine or primitive (FIG. 9) which provides session layer functions. The calling process also provides both its network standard address (NSA) and the NSA of the called or destination end-point process. In addition, the calling process, upon issuing the call, may provide certain additional parameters. These parameters may include flow control information (window size), a requirement for end-to-end assurance and upper limits of the number of bytes in each information unit (IU) for receiving and sending information.

Upon being invoked, the IPC-Connect (session layer) routine advances to step 850. In step 850, certain parameters are validated, such as the format of the network standard addresses. The routine then advances to decision 851 and decision 851, in turn, advances the routine to step 852 in the event that the validating step indicates that the NSAs have an improper format. In step 852, an error return is generated and returned to the user process to indicate to the user process that the call will not be handled. In addition, control is returned to such user process.

Assuming, however, that the NSAs (and other parameters) have an appropriate format, decision 851 advances the IPC-Connect primitive to step 853. In step 853, an attempt is made to allocate a session layer control block (CB) of memory to store session layer information for this particular connection and, in addition, a circuit number is allocated and placed in the CB (if available) to identify this specific circuit. The routine then advances to decision 854 where a determination is made as to whether resources for this allocation were available.

In the event that resources were not available, decision 854 advances the routine to step 852 where the error return is generated and the control is returned to the user process. Alternatively, if resources are available, decision 854 advances the routine to step 856. In step 856, information supplied by the user process is copied into the CB. This user-supplied information includes the NSAs of the user and the destination end-point processes and other parameters. The routine then advances to step 857. In step 857, a setup transaction buffer is allocated, the size of the buffer thus allocated including enough room to store connection information that will be provided by this session layer and the subsequently described transport and network layers. The routine then advances to decision 858.

In decision 858, a determination is made as to whether there were adequate resources for the allocated setup transaction buffer. If the resources are inadequate, decision 858 advances the routine to step 852 where an error return is generated and control is returned to the user process. If the resources for the allocated setup transaction buffer are adequate, decision 858 advances the routine to step 860.

In step 860, appropriate transaction information is copied into the setup transaction buffer. It is noted that the setup transaction buffer is structured to store specific types of information in predetermined portions of the buffer. Advantageously, therefore, information such as the NSAs of the user and remote destination processes and the circuit number are inserted in portions of the buffer specifically reserved for this information. User process supplied parameters, such as the upper limit of the number of bytes for sending/receiving each IU, the window size and the requirement (if any) for end-to-end assurance, may also be copied into predetermined portions of the buffer. In addition, data designating this transaction type which, in this case, constitutes a call setup or connect request, is also inserted into the buffer.

After copying the above information into the setup transaction buffer, the routine advances to step 861 where an indication that this circuit is in the connecting state is set into the control block. The routine then advances to step 862 where the buffer address of the setup transaction buffer is placed on an IC queue and a signal is sent to the IC switching routine. The IPC-Connect routine then advances to step 865, the circuit number is obtained from the control block and a notification is returned to the user process, which notification contains the circuit number. The IPC-Connect routine or primitive then advances to step 866 to return a "normal" completion code to the user process.

When control is obtained by the IC switching routine from the session layer IPC-Connect routine, the IC switching routine advances to step 870 (FIG. 10). In step 870, the buffer address is obtained from the queue for the transport layer's use and control is passed to the outgoing Transport Layer routine.

The outgoing Transport Layer routine, upon being called, advances to step 871. In step 871, the information in the buffer is read out. The routine then advances to step 872. In step 872, the routine notes from the setup transaction buffer that the transaction constitutes a call setup and, upon noting this type of transaction, checks the validity of the other information in the buffer to determine whether the format of the other information is reasonable. Criteria such as the amount of information and content of information may be advantageously used. The routine then advances to step 873.

In step 873, a control block (CB) for the Transport Layer routine is allocated. In step 874, the NSAs of the originating and terminating processes and the circuit number are copied from the setup transaction buffer into the control block. An identification of the state of the transaction layer is set into the control block in state 875, which present state, as previously mentioned, constitutes the call setup or connecting state. At this time, the routine then advances to step 878.

In step 878, the structured information in the setup transaction buffer is copied into a reserve buffer to provide duplicate transaction information. The information is thus saved in the event that there is a later setup retry. The routine thereupon advances to step 879.

In step 879, certain ones of the user parameters are moved from the setup transaction buffer into the Transport Layer routine control block. Such information might advantageously include flow control information (including window size) and a requirement for end-to-end assurance. The routine thereupon advances to step 880 where transport layer parameters, such as the flow control and assurance requirement information, are copied into the setup transaction buffer.

After the Transport Layer routine parameters are copied into the setup transaction buffer, the routine advances to step 882 where a start call timer operation is initiated. The buffer address of the setup transaction buffer is then placed on the IC queue as shown in step 883 and in step 884 the Transport Layer routine returns control to the IC switching task.

If the subsystem is part of an interface process, it is noted that (as described hereinafter) the interface process also passes control to the IC switching routine at this point when processing a connection from a remote machine. (In this event, this IC Subsystem will only provide network layer functions).

In either of the above events, the IC switching routine, upon obtaining control, advances to step 888 (FIG. 11) where the routine obtains the address of the setup transaction from the queue (or the transaction buffer address from the IPI or TNI interface process) and then transfers control to the Network Layer routine. The Network Layer routine, in turn, advances to step 889 where it reads the transaction. The information from the buffer is then read out and the routine advances to step 890. In step 890, a control block is allocated for the network layer and the NSAs of the end processes are copied from the setup transaction or interface buffer into the Network Layer routine control block and a path descriptor (comparable to the circuit number) is placed in the CB. This advances the outgoing Network Layer routine to step 891.

In step 891, a routing algorithm is invoked to determine the identity (ID) of the process that constitutes the next (or only) link in the connection. More specifically, the NSAs of the terminating end-point and user processes are obtained from the control block and a routing table is accessed to identify an available route between the user and this terminating end-point process. If the terminating end-point process is in the same processor as the user process, the routing algorithm identifies the ID of this terminating end-point process. In the event that the terminating end-point process is in a different processor or machine, the algorithm identifies the ID of the interface process through which the connection will extend.

After invoking the routing algorithm, the Network Layer routine advances to decision 892. In decision 892, a determination is made as to whether the above-described routing has been successful. If there is a lack of success, the routine goes to step 893 to send an abort back to the outgoing Transport Layer routine and return control to the IC switch routine which, in turn, will call such Transport Layer routine. Alternatively, if the routing is successful, decision 892 advances the routine to step 895. In step 895, a determination of the connection type is made by referring to the process IDs and NSAs. More specifically, it is determined whether this connection will go directly to another process in this machine or will go by way of an interface process to a process in another processor or machine. This information is recorded in the Network Layer routine control block.

After the entering of the above-described information, the routine advances to decision 897 where a determination is made as to whether a port to the next process in the link presently exists, which port constitutes buffer memory that will be shared by this outgoing Network Layer routine and the incoming Network Layer routine of the next process. More specifically, this determination is made by comparing the process identity (PID) with the appropriate field of port descriptors in local memory. In the event that a port to the remote process does not exist, shared buffer area is allocated and a port to the PID is thus initialized as depicted in step 898. At the same time, the port descriptor, that is, identification of the PID and the address of the shared buffer, is entered into the local memory. The routine then advances to step 899. Alternatively, if this port is presently in existence due, for example, to another connection existing between the two processes, decision 897 advances the routine directly to step 899.

In step 899, the port to the PID is identified in the Network Layer routine control block. More specifically, a pointer is entered into the control block pointing to the port descriptor which, in turn, points to the address of the port. At the same time, a count in the port descriptor is incremented to indicate to the port that another Network Layer control block is connected thereto. The routine then advances to step 900. In step 900, the information from the setup transaction buffer is written into the port and in step 901 a port message counter and a message pointer are updated. More specifically, the message counter is incremented to indicate an additional transaction in the port and the message pointer is moved to point to the next buffer area in the port available for writing the next transaction.

The routine advances to step 902 which will signal the next process in the link, as identified by the routing algorithm. More specifically, in step 902 a buffer is allocated and the port index is inserted in the buffer. This buffer is then passed to the next process by mapping the buffer into a queue in the address space of such next process, using the PID of the next process as an argument to locate the queue. Control is then returned to the IC Switch routine and in step 903 the IC Switch routine terminates the actions taken by the IC Subsystem of the user process in response to the "connect" request.

The buffer passed to the next process in the link is received by the IC Switch routine in such next process, awakening the task which advances to step 905 (FIG. 12). The IC Switch routine, in step 905, calls the incoming Network Layer routine and the incoming Network Layer initially determines (step 904) whether a port presently exists (which condition would be present if the two processes are involved in another call). If a port does not exist, the routine advances to step 908. In step 908, a port descriptor is allocated and initialized. More specifically, a pointer is created to point to the port identified by the port index that was obtained from the passed buffer. In addition, the ID of the originating (or prior) process is obtained from the setup transaction and copied into the port descriptor with the port index. The routine then advances to step 906.

If a port presently exists, decision 904 advances the routine directly to step 906. In step 906, the Network Layer routine allocates a setup transaction buffer, setting aside enough room in the buffer for itself and the transport and session layers. With the port index in the passed buffer available, the incoming Network Layer routine in step 906 copies the transaction contained in the port into the setup transaction buffer. The routine then advances to step 907 and allocates a Network Layer control block. The NSAs in the setup transaction are then copied into the Network Layer control block. Upon completion of the copy of the NSAs the routine advances to step 909. In step 909, the control block is associated with the port by providing a pointer to point at the port descriptor.

After associating the control block with the port, the routine advances to step 910. In step 910, a determination is made of the connection type by reference to the source and destination NSAs and PIDs. More specifically, it is determined whether or not this call is passing through the IC subsystem of an interface process which is an intermediate link to an end process or is presently within a destination or ultimate end process (it being noted that an interface process can be an end process). In the event that this is an interface (IPI or TNI) process which terminates an intermediate link, the routine will then pass control to the Network Layer Interface task of such interface process, as described in more detail hereinafter. Alternatively, if the IC subsystem is in an ultimate destination process, this routine will then advance by way of a second branch to step 911. In step 911, the address of the setup transaction buffer is placed in the IC queue. The Network Layer routine then returns control to the IC switch, which in step 912 obtains the transaction buffer address and calls the Transport Layer routine.

The Transport Layer routine, upon being called, advances to step 915 (FIG. 13). In step 915, the Transport Layer routine reads out the setup transaction. The routine then advances to step 916 where it determines whether the format of this setup transaction is valid. In the event that the format is not within appropriate validity criteria, an abort is returned to the Network Layer routine in step 917 and the routine is terminated by returning control to the IC switch. Assuming, however, that the format is appropriate, the routine advances to step 918 where a control block is allocated. In step 919, the NSAs are then copied from the setup transaction into the control block. The routine advances to step 920 and in step 920 the state of the control block is set to "called". After the called state is set into the control block, the routine advances to step 922.

In step 922, negotiating parameters obtained from the setup transaction are copied into the control block. More specifically, parameters such as the window size and end-to-end assurance requirement are written into the control block. The routine then advances to step 923 where the address of the setup transaction buffer is placed in the IC queue and thereafter control is returned to the IC Switch routine. The IC Switch routine in step 924 then proceeds to obtain the address of the setup transaction buffer and call the Session Layer routine.

When the Session Layer routine is called, it advances the routine to step 930 (FIG. 14). In step 930, the incoming Session Layer routine extracts the transaction information from the queue, which information includes, for example, the various negotiation parameters such as the window size and the end-to-end assurance requirement. The incoming Session Layer routine then advances to step 931 to determine the number of connection requests that are presently queued for the session layer of this process. When that determination is made, the routine advances to decision 932. In accordance with decision 932, if there are too many requests presently queued for this connection, the routine advances to step 935. In step 935, the incoming call is refused and an appropriate refuse response is returned to the outgoing Transport Layer routine. The Session Layer routine then goes to step 936 which will return control to the IC switch, the IC switch in this case terminating the operation of the IC Subsystem.

Assume now that there are a limited number of queued requests which are fewer than a selected threshold. In this case, decision 932 advances the Session Layer routine to decision 933. In step 933, the routine determines whether or not this user process has issued an IPC-Listen request (described below). If an IPC-Listen request has not been issued, the Session Layer routine advances to decision 934. If at least one unsatisfied request is presently queued, decision 934 advances the routine to step 935 wherein a refuse is returned to the Network Layer routine, as previously described, and control is returned to the IC Switch routine to end the call by terminating the operation of the IC Subsystem.

Assuming that the user process has issued a "listen" request or alternatively, if such a request has not been issued but no other requests are queued and waiting, then either decision 933 or decision 934 advances the Session Layer routine to step 940 (FIG. 15).

In step 940, a control block is allocated for the Session Layer routine. The routine advances to step 941 and at this time information from the incoming setup transaction (such as negotiation parameters) is copied from the transaction buffer into the control block. The routine then advances to step 942 and in step 942 the incoming connection request is placed on the SL subsystem queue for later use by the user process. More specifically, the information will be subsequently used hereinafter by the IPC incoming CD routine invoked by the user process. This information, as placed on the queue, will include the NSAs, the negotiating parameters and the circuit number. In addition, certain user data may also be included (such as data provided to open up the database which is described in detail hereinafter). After all of this information is placed on the SL subsystem queue, the routine advances to decision 943. In decision 943, a determination is made as to whether the user process has issued an IPC-Listen request. If such a request has been issued, decision 943 advances the routine to step 944. In step 944, the user process is notified that the incoming connection request has been placed on the SL subsystem queue. The routine then advances to decision 946. Alternatively, if the user process has not issued an IPC-Listen request, decision 943 advances the routine directly to decision 946.

Decision 946 determines whether or not this is a "Redirected" connection request (described in detail below). In the event that this does not constitute a "Redirect" request, the routine advances to step 947. Step 947 returns control to the IC switch whereupon the routine terminates and returns control to the IC Switch routine for normal termination. At this point, the request awaits removal from the subsystem queue by the IPC incoming CD primitive.

Assume now that this constitutes a Redirect Connection request. In that event, decision 946 advances the routine to step 949. Under this condition a new transaction buffer is allocated and a "redirect confirmation" is copied into the buffer. The buffer address is then placed on the Transport Layer routine queue. The routine then advances to step 950 where it returns to the IC Switch routine for normal termination.

As previously noted, when an application process is called, the call connection is initially directed to ACP process 119 which, in part, determines whether the application process is in existence and, in the absence thereof, initiates the creation of the program image of the application process. Thereafter, the ACP process redirects the previously setup connection to the application process (MAP-ISP 126, for example) and drops out of the connection. The resultant connection is therefore between the originating user process and the application process. "Redirection" can also be initiated by other (called) processes (DBWM 131, for example) to redirect calls to other types of terminating end-point processes (such as DBS 130). In any event, the (called) process initializes this redirecting of the connection by invoking a "redirect" primitive in its IC Subsystem 136 (which primitive may be considered as constituting the internal communication session layer). This advances the primitive to step 400 (FIG. 16).

In step 400, the "redirect" primitive validates the parameters of the command issued by the (called) process. This validation step can be considered as being substantially identical to the previously described validating step 850 provided by the outgoing-connect Session Layer routine of a process making a call differing only in that there may be minor differences in the substance of the parameters. The routine (or primitive) then advances to decision 401.

In decision 401, a determination is made as to whether the parameters validated are appropriate. If they are inappropriate, decision 401 advances the routine to step 404 where an error and abort command is generated and returned to the (called) process, terminating at the same time the "redirect" routine. Alternatively, if the parameters are appropriate, decision 401 advances the routine to step 402.

In step 402, a redirect transaction descriptor-buffer is allocated with enough buffer area for the redirect command and for header data that will be inserted by the several layers. The routine then advances to decision 403 where a determination is made as to whether or not there were adequate resources for the buffer. If the resources are inadequate, decision 403 advances the routine to step 404 where an error message is generated and returned to the user process and the connection is aborted. Alternatively, if there are adequate resources, decision 403 advances the routine to step 408.

In step 408, user process supplied information in the command is "formatted" into the redirect transaction descriptor-buffer, such formatting and the information thus formatted being substantially identical to the format and information provided in the previously described step 860 in the outgoing-connect Session Layer routine. Step 408 of the "redirect" primitive differs, however, in that the ultimate end-point process ID, which is supplied, in this case, by the redirecting (called) process, is at this time inserted in the redirect transaction descriptor-buffer. The routine now advances to step 409 and in this step the state of the control block (priorly allocated and formatted) during call setup) is set to "redirect". The routine now advances to step 410 and in step 410 the address of the transaction descriptor-buffer is placed on the IC queue. At the same time, the IC Switch routine is signaled and the routine advances to step 411 where it returns "normal" to user process.

The IC Switch routine, upon being signaled, advances to step 412. In step 412, the IC switch task proceeds to obtain the address of the transaction descriptor-buffer from the queue and then turn over control to its outgoing "redirect" Transport Layer routine. This advances the Transport Layer routine to step 413.

In step 413 (FIG. 17), the outgoing "redirect" Transport Layer routine reads the "redirect" transaction. This advances the routine to step 414 which validates that the present state of the Transport Layer control block is the "connect" or "setup" state and changes the state to "redirect". The routine then advances to step 418 and the buffer address of the redirect transaction descriptor is placed on the IC queue and control is passed back to the IC switch.

In step 420, the IC switch task now obtains the buffer address of the descriptor from the queue and turns control over to its outgoing-redirect Network Layer routine. This advances the routine to step 421. In step 421, the redirect transaction descriptor is obtained from the buffer. The routine then advances to step 422 and the present state (setup or connection) of the Network Layer control block is validated and the control block is set to the new "redirect" state. The routine thereupon advances to step 423.

In step 423, the identification of the shared port used in the original connection setup is made and the "redirect" transaction is written into the port. The routine thereupon advances to step 424 where the port message count and the port pointers ae updated (in a manner similar to the previously described updating step 901 in the outgoing setup or connection Network Layer routine). At this point, the outgoing redirect Network Layer routine advances to step 425 wherein it signals the remote process at the other end of the connection which, in this case, is the process originally setting up the connection and passes a buffer with the port index and the port ID to this originating process. The outgoing redirect Network Layer routine then returns control to the IC Switching routine which, in step 426, proceeds to retire and terminate the IC Subsystem functions.

In the originating or source process, the IC Switch routine is awakened by the signal received from the process originating the "redirect" request. The IC Switch routine, in step 430 (FIG. 18), then turns over control to its incoming/outgoing redirect Network Layer routine. The Network Layer routine thereupon advances to step 432 wherein it obtains the passed buffer identifying the port ID and containing the port index. In step 432, the Network Layer routine allocates a transaction buffer and, utilizing the port identification from the passed buffer, proceeds to read the transaction from the port into the allocated transaction buffer. The routine then advances to step 433 where it validates that the control block is presently in the "setup" state and changes this state to "redirect requested". At this time the routine advances to step 434 where it proceeds to allocate another Network Layer control block (in addition to the CB allocated during call setup). The routine then advances to step 435.

In step 435, the old path descriptor in the old control block is swapped into the new control block. This will prepare an arrangement for the Transport Layer control block to be now associated with the new control block. At this point, the routine advances to multiple step 436 which corresponds to steps 891-902 in the outgoing Network Layer routine previously described. More specifically, in step 436 the routing algorithm is invoked to determine the remote process ID for this circuit, a connection type is determined and the Network Layer control block is associated with a port shared with such remote process. The "redirect" transaction is thereupon written into the port and the message counter and pointers are updated, the remote process is signaled and a buffer with the port ID and the port index is passed to the remote process. Meanwhile, the Network Layer routine advances to step 438 where the routine sets the state of the new control block to "redirecting". Control is then passed back to the IC switching routine which in step 440 retires. The routine then advances to step 437 where it returns to normal.

The IC switching task in the ultimate destination end-point (callee) process, upon receiving the signal and the passed buffer, awakens and passes control to its incoming Network Layer routine. The Network Layer routine thereupon institutes a series of steps which are identical to the steps taken by the incoming Network Layer routine during the call setup state. Control is then passed on through the incoming Transport Layer routine and incoming Session Layer routine which correspondingly proceed through the same function steps as previously described for the incoming Transport Layer routine and the incoming Session Layer routine during call setup. Consequently, the transaction is passed to the callee or terminating end-point process (in the event that it has issued a "listen" request). As a consequence, the terminating end-point process is now notified that there is an incoming call and that a connection has now been prepared from the originating end-point process to the callee or terminating end-point process, subject to the callee's acceptance.

As previously noted, with respect to decision 946 of the incoming-connect Session Layer routine, a determination is made as to whether the transaction constitutes a "redirect-connection" request. In this case, the request is a "redirect-connection" request and decision 946 advances the Session Layer routine to step 949 where a new transaction buffer is allocated, a "redirect confirmation" transaction (command) is generated and placed in the buffer, the buffer address is placed on the IC queue and control is returned to the IC Switch routine. The IC Switch routine, in turn, as depicted in step 441 (FIG. 19), obtains the buffer address from the IC queue and then turns control over to its outgoing-redirect-confirm Transport Layer routine.

The outgoing-redirect-confirm Transport Layer routine, in step 442, obtains the confirmation transaction and identifies this transaction type. In step 443, the Transport Layer routine then changes the state of the connection in its control block to "called". Then, in step 444, the Transport Layer routine places the buffer address of the confirmation transaction on the IC queue and turns control back to the IC switch. In step 445, the IC switch obtains the buffer address and passes control to the outgoing-redirect-confirmation Network Layer routine.

In step 450, the outgoing Network Layer routine obtains the transaction. In step 451, the Network Layer routine changes the state of the connection (as identified in its control block) to "setup requested". The Network Layer routine then advances to step 452 where it writes the confirmation transaction into the port that it now shares as part of the connection between the callee or terminating end-point process where the routine runs and the originating end-point process. In step 453, the Network Layeer routine updates the port message counter and pointers. The routine advances to step 454 where it passes a buffer identifying the port ID and port index to the remote originating end-point process and returns control to the IC switch routine which in step 455 retires.

At the caller (originating) end-point process, the IC Switch routine picks up the signal from the network layer of the callee process. This awakens the task which in step 456 (FIG. 20) obtains the address of the port from the passed buffer and passes control to the incoming-redirect-confirmation Network Layer routine. The Network Layer routine in step 457 allocates a transaction buffer and reads the transaction from the port into the allocated buffer. The routine now advances to step 459 where it deletes any association between the two Network Layer control blocks of the "originating" and the "redirecting" processes to preclude subsequent information from passing between the process requesting the "redirect" and the originating end-point process. At the same time, a "clear" command or transaction is generated and passed on to the process requesting the "redirect". This will result in the remote "redirect" requesting process clearing and disconnecting the connection, as explained in more detail hereinafter. At this point, the Network Layer routine returns control to the IC Switch routine which in step 460 retires.

When a terminating end-point process has allocated a buffer for storing a received "connect" request or a "redirect" request, has issued a "listen" request and has received an incoming "connect" or "redirect" transaction from its session layer, it accepts this incoming request by issuing an "accept". This invokes an "Accept" primitive which constitutes the outgoing Session Layer. The primitive upon being invoked advances to step 462 (FIG. 21).

In step 462 this Session Layer primitive (or routine) verifies certain parameters provided by the "accepting" process. For example, in this step the Session Layer routine verifies that it has received an appropriate location for the user buffer for storing the "connect" (or "redirect") transaction and has been supplied a buffer for defining the length of the transaction or message. The routine then advances to decision 464 which determines whether these parameters are within acceptable limits. If the parameters are invalid, the routine proceeds to step 472 which generates an error indicating message to be returned to the user process. In addition, step 472 terminates the routine.

Assuming that the parameters are within the proper limits, decision 464 advances to step 463. In step 463, the Session Layer control block is located and the present (connect) state is validated. In decision 465, it is determined whether the control block is in the appropriate state and, if the state is inappropriate, the routine advances to step 472 which returns an error message, as described above. Assuming that the control block is in the appropriate state, the routine advances to step 466. In step 466, the Session Layer routine allocates a transaction buffer, generates a transaction (accept) message and writes the user supplied message into the buffer. In decision 467, if there are inadequate resources for the transaction buffer, the routine advances to step 472 where the error message is generated and returned as described above. If the resources are adequate, decision 467 advances the routine to step 468.

In step 468, the above-described parameters received from the originating end process are examined and compared with parameters received from the accepting terminating end (user) process. These include such parameters as the size of the information unit, various assurance options and delivery confirmation. In step 468, a determination is made as to whether there is compatibility of the negotiating parameters of the originating end and terminating end processes. If these parameters are incompatible, decision 469 advances the routine to step 472 where an error message is generated and returned to the accepting process. Alternatively, if the parameters are compatible, decision 469 advances the routine to step 470 where user data including the negotiated parameters are formatted into the transaction buffer. The routine then advances to step 474 where the state of the control block is changed to "data transfer". In step 475, the address of the transaction buffer is placed on the IC queue and the IC Switch routine is signaled. The routine in step 476 then returns to normal.

The IC Switch routine in step 478 (FIG. 22) is awakened by the signal from the session layer. In step 478, the routine obtains the buffer address of the "accept" transaction from the queue and turns control over to its outgoing accept Transport Layer routine. This advances the Transport Layer routine to step 479 where, when control is transferred to it, it obtains the accept transaction. The routine then advances to step 480 to validate the transaction format and confirm the present state in the control block (which present state, as described above, is either "connect" or "redirect"). The routine then advances to step 483 where it extracts certain of the negotiated parameters from the transaction (such as end-to-end assurance, delivery confirmation and/or window size). The routine then advances to step 485 and, in this step, places the address of the transaction buffer on the IC queue and turns control back to the IC Switch routine. Thereafter, in step 486, the Transport Layer routine changes the state of the control block to "data transfer" and, in step 481, returns to normal.

The IC Switch routine, upon being returned control, goes to step 482. In step 482, it proceeds to obtain the address of the transaction buffer from the queue and pass control to its outgoing accept Network Layer routine. This advances the outgoing accept Network Layer routine to step 488. In step 488, the Network Layer routine obtains the transaction from the buffer. In step 489, the Network Layer routine validates the state of th connection defined by the control block. In step 490, it changes this state to "data transfer". The routine then advances to step 491 and, in this step, writes the "accept" transaction into the port shared by the terminating end process (which is the user process) and the originating end process. In step 492, it updates the port message and the port pointers. In step 493, the remote originating end process is signaled via a buffer passed to the remote process identifying the shared port address. Control is then returned to the IC Switch routine and in step 494 the Network Layer routine returns to normal. In the meantime, in step 495, the IC Switch routine, upon obtaining control, proceeds to retire.

At the remote originating end-point process, the IC Switch task is awakened by the signal from the accepting process. The IC Switch routine in step 496 (FIG. 23) proceeds to turn control over to its incoming accept Network Layer routine and the Network Layer routine advances to step 497. In step 497, a transaction buffer is allocated and the transaction in the port is written into this transaction buffer. In step 498, the port pointers and message counter are updated. The control block circuit state ("connect" or "redirect") set into the control block is validated in step 499. This circuit state is changed to "data transfer" in step 500. The routine then advances to step 501 where it places the address of the transaction buffer on the IC queue, passes control back to the IC Switch routine and advances to step 503 where it returns to normal.

The IC switch task upon regaining control advances to step 502 and, in this step, obtains the address of the transaction buffer from the queue and transfers control to its incoming accept Transport Layer routine. This advances the Transport Layer routine to step 504 where it obtains the transaction. In step 505, the format of the transaction is validated as is the connection state in the control block. In step 507, negotiation parameters in the transaction are examined; end-to-end assurance, delivery confirmation and window size parameters are extracted and placed in the control block. The address of the transaction buffer is then placed on the session layer queue in step 508. The routine then advances to step 509 where it changes the "connect" state in the control block to "data transfer". The routine then advances to step 510 where it returns to normal and sends control back to the IC Switch routine.

The IC Switch routine, upon returning control, obtains the transaction buffer address and passes control to the incoming accept Session Layer routine as depicted in step 511. This advances the incoming accept Session Layer routine to step 512 (FIG. 24) where it obtains the transaction from the buffer. In step 514, the Session Layer routine validates the format of the transaction and identifies that the connection state of the control block is appropriate. In step 515, the Session Layer routine examines the negotiation parameters and copies these parameters into its control block. In step 516, the Session Layer routine then writes the transaction data into the message buffer supplied by the user process. The Session Layer routine then advances to step 517. In step 517, the control block state is set to "data transfer". The routine then advances to step 518 where the user process is notified that the "accept" transaction has been received. The routine then advances to step 519 which returns the routine to normal and also returns control to the IC Switch routine, which retires in step 513.

Either one of the end-point processes will desire to terminate the connection after the communication session has been completed or if there has been an error condition arising during a transaction. To terminate the connection, the user process issues a "disconnect" primitive specifying an optional cause code. This primitive constitutes the outgoing Session Layer routine. Upon being invoked, the Session Layer routine advances to step 951 (FIG. 25).

In step 951, the Session Layer routine confirms that the cause code calling for the disconnect is within an appropriate range. The routine then advances to decision 952. If the code is beyond the proper range, decision 952 advances the routine to step 955 where an error response is returned to the user process and the routine retires. Alternatively, if the cause code is in the appropriate range, decision 952 advances the routine to step 953.

In step 953, the Session Layer control block for this particular connection is located and the state of the connection is identified. The routine then advances to decision 954 where it is determined whether this is the appropriate connection descriptor for this connection and whether the connection is in the appropriate state to provide the "disconnect" function. If these conditions are inappropriate, the task advances to step 955 which returns the error message to the user process and retires the routine. Alternatively, if the connection descriptor and the connection state are appropriate, decision 954 advances the routine to decision 956.

In decision 956, it is determined whether the connection is already in the "disconnect" state due, for example, to a prior disconnection from the remote process. If the connection is in the "disconnect" state, decision 956 advances the Session Layer routine to step 957. In step 957, the Session Layer routine is cleared of any events, such as the generation or maintaining of any signaling to the user. In addition, the Session Layer control block is freed and the routine advances to step 958 to provide the normal return. Alternatively, if the state of the connection is not presently "disconnected", decision 956 advances the routine to step 959.

In step 959, all events for this current connection that are or may be returned to the user are cleared. The routine then advances to step 960. In step 960, an STCLEAR transaction is generated and placed in the transaction buffer, the buffer address is sent to the IC queue, the IS Switch routine is signaled and the Session Layer control block state is changed to "disconnected". The Session Layer routine then advances to step 961 where it provides the normal return.

When the IC Switch routine or task receives the signal from the Session Layer routine, it awakens and advances to step 962. In step 962, the IC Switch routine obtains the transaction buffer address from the queue and transfers the control to its outgoing disconnect Transport Layer routine. This advances the outgoing disconnect Transport Layer routine to step 963. In step 963, the routine reads the transaction from the buffer. The routine then advances to step 964 where it changes the state of the Transport Layer control block to "disconnect". The routine then advances to step 965 and, in this step, places the transaction buffer address in the IC queue and returns to the IC Switch routine. The IC Switch routine, upon regaining control, advances to step 966.

In step 966, the IC Switch routine obtains the buffer address from the queue and transfers control to its outgoing disconnect Network Layer routine. This advances the Network Layer routine to step 967 (FIG. 26). In step 967, the routine obtains the transaction from the buffer and advances to step 968. All of the timers associated with this connection are cleared in step 968 and, in step 969, the state of the Network Layer control block is changed to "clearing". The routine then advances to step 970 where an "outgoing clear" transaction is generated and, in step 971, the transaction is copied into the port shared by the two processes connected by this link. The port message count and the pointers are updated in step 972 and, in step 973, the remote process is signaled via the passed buffer and, in addition, control is returned to the IC Switch routine. The IC Switch routine, upon regaining control, thereupon retires in step 974.

The IC Switch routine of the remote process in this connection picks up the signal from the outgoing disconnect Network Layer of the other process and, upon being thus awakened, advances to step 975 (FIG. 27). In step 975, the IC Switch routine obtains the passed buffer and transfers control to its incoming disconnect Network Layer routine and the Network Layer routine advances to step 976. In step 976, the transaction is obtained from the shared port. The port message count and pointers are updated in step 977 and, in step 978, all timers associated with the connection are cleared. The routine then advances to step 979 where the state of the Network Layer control block is changed to "clearing". In step 980, an "incoming clear" transaction is generated and placed in a transaction buffer. In step 981, the address of the transaction buffer is placed on the IC queue and control is returned to the IC Switch routine.

The IC Switch routine in step 982 turns control over to the incoming clear Transport Layer routine and this routine reads out the transaction in step 984 (FIG. 28). The Transport Layer routine then advances to step 985 where it generates a "clear confirm" transaction and places this transaction in a newly allocated buffer. In step 986, the address of this buffer is placed on the IC queue. In step 987, the Transport Layer control block is freed up and the "clear" transaction received from the Network Layer routine is changed to a "disconnect" transaction in step 988. The buffer address for this "disconnect" transaction is placed on the IC queue in step 989 and control is returned to the IC Switch routine.

The IC Switch routine in step 990 obtains the buffer address and signals the incoming STCLEAR Session Layer routine and the Session layer routine advances to step 655 where it obtains the transaction from the buffer and locates the Session Layer control block for this connection. The routine then advances to decision 656 where a determination of the present state set into the control block is made. If the control block state is presently in the "connect" state, the routine advances to step 658 and, in step 658, the control block is freed. The routine then returns control to the IC Switch routine. Alternatively, if the Session Layer control block is presently in the "data transfer" state, decision 656 advances the routine to step 659 wherein the user process is signaled that an incoming "disconnect" transaction is being received in this connection. After the user is signaled, the Session Layer routine returns control to the IC Switch routine. In the event that the Session Layer control block is in the "disconnecting" state, the user in step 657 is signaled that an incoming "disconnect" has been received. Since this might occur if the user had priorly sent the "disconnect", the decision is left to the user process to determine what next step will be taken. The Session Layer routine then returns control to the IC Switch routine. In all of these events, when control is returned to the IC Switch routine, it advances to step 660.

In step 660, the IC Switch routine obtains the "clear confirm" transaction buffer address placed there by the Transport Layer and turns control over to its outgoing clear confirm Network Layer routine. This advances the Network Layer routine to step 662 (FIG. 29). In step 662, the Network Layer routine obtains the "clear confirm" transaction from the buffer and, in step 663, generates an outgoing "clear confirm" transaction. This transaction is placed in the shared port in step 664 and, in step 665, the port message count and the pointers are updated. A buffer is then passed to the remote process in step 666 identifying the address of the port. Thereafter in step 667, the routine disassociates the circuit from the port by nulling the port address in the CB. Control is then returned to the IC switch and, in step 668, the IC Switch routine retires.

The IC Switch routine in the remote process is awakened by the signal from the outgoing network layer and, in step 670 (FIG. 30), obtains the port buffer and turns control over to its incoming "clear confirm" Network Layer routine. In step 671, the incoming Network Layer routine reads out the "clear confirm" transaction in the port. In step 672, the port message count and pointers are updated and the Network Layer routine generates an incoming "clear confirm" transaction in step 673 and places it in a transaction buffer. The address of the transaction buffer is then placed in the IC queue in step 674. In step 675, the circuit is disassociated in the port by nulling the port address in the PCB. The routine then advances to decision 676 (FIG. 31) where a determination is made as to whether the port is being used by another circuit connection between the two processes. If another circuit is using the port, decision 676 advances the routine to a normal return and returns control to the IC Switch routine. Alternatively, if no other circuit is using the port, decision 676 advances the routine to step 678.

In step 678, a "port release" message is generated and written into the shared port. The port message count and pointers are updated in step 679 and, in step 680, a buffer is passed to the remote process and the remote process is signaled thereby. The Network Layer routine then advances to step 681 where the port descriptor is de-allocated by eliminating the port address and the port buffer is released. The routine then returns control to the IC switch routine which, in step 677, obtains the transaction buffer address from the queue and turns control over to the incoming "clear confirm" Transport Layer routine.

The Transport Layer routine, upon obtaining control, advances to step 685. In step 685, the Transport Layer routine reads the "clear confirm" transaction from the buffer and then advances to decision 686. In decision 686, the Transport Layer routine determines from its control block whether the Session Layer routine has issued a "disconnect". If a "disconnect" has not been issued by the Session Layer, decision 686 advances the routine to step 687. In step 687, a "disconnect" transaction is generated and, in step 688, this transaction is sent on to the Session Layer routine for passage to the user process. After a "disconnect" transaction is sent to the Session Layer, the routine advances to step 689. Alternatively, if the Session Layer has issued a "disconnect", as described above, decision 681 advances the routine directly to step 689. In step 689, the Transport Layer control block is de-allocated by freeing up the information stored therein and the buffer area is released. The control is then returned to the IC Switch routine which, in step 690, retires.

In the remote process, the IC Switch routine is awakened by the signal from the incoming clear confirm network layer. The IC Switch routine, in step 691 (FIG. 32), turns control over to the incoming "port release" Network Layer routine. In step 692, the Network Layer routine obtains the "port release" message from the passed buffer. Upon reading out the "port release" message, the Network Layer routine advances to step 693 where it de-allocates the port descriptor by releasing the buffer memory and, in addition, releases the port buffer. Since the port buffer has now been released by both Network Layer routines, it is now returned to the common pool where it is now available for other connections. The Network Layer routine now returns control to the IC Switch routine and, in step 694, the IC switch routine retires.

When a connection has been established between two processes by the Internal Communication Subsystem, either process may write data as an information unit (I.U.) to the connection between it and the other connected process. To write data to an established connection to another process, the sending process issues a call to a "write" primitive or routine which provides the session layer functions of the IC Subsystem.

When the call issued by the sending process is received by the "write" routine, the routine initially advances to step 520 (FIG. 33). In step 520, the parameters are validated, such as noting the number of bytes in the information unit that the sending process is writing and insuring that the number does not exceed a predesignated threshold. Decision 523 then advances the routine to step 526 in the event that the threshold has been exceeded; namely, in the event that the size of the information unit is excessive. In step 526 an error message is generated and returned to the sending process to indicate to the process that the call is not being accepted and that control is being returned to such sending process.

Assuming now that the size of the information unit does not exceed the predefined threshold, decision 523 advances the routine to step 521. In step 521, the virtual call circuit number (supplied by the sending process) is identified and the circuit number is inserted into the header of the information unit. In addition, in step 521 the routine performs status and flow control checks using flow control information in the control block. This information was obtained from header information piggybacked on data flowing in the reverse direction through this connection. The purpose of these checks is to determine whether the connection to the remote end-point process will accept data. Decision 524 advances the routine to step 522 after the connection is identified and a determination is made that the connection is in the appropriate condition to accept data for passage therethrough. Alternatively, the routine is advanced to step 526 in the event that there is a bad connection state or there is a control of flow in effect.

Assume that decision 524 has advanced Session Layer routine to step 522. In step 522, buffer space internal to the outgoing side of the I.C. Subsystem is allocated for the information unit. At this time, decision 525 determines whether there are sufficient resources for the data storage and in the event that the resources are inadequate the Session Layer routine advances to step 526. Alternatively, if the resources are ample, the routine proceeds to step 530.

Assume now that decision has advanced the Session Layer routine to step 530. In step 530, the information unit is read out of the sending process storage area and written into the outgoing IC buffer area. The buffer area address is placed in the IC queue and the IC Switch routine is then signaled. The routine then advances to decision 531 where it is determined whether or not the connection requires delivery confirmation. In the event that no delivery confirmation is necessary, the routine goes to step 532 which functions to signal the sending user process that the Session Layer routine has written the IU into the connection. The routine thereupon advances to step 533 which constitutes its normal completion and return. Alternatively, if the connection requires delivery confirmation, the routine advances directly to step 533 without signaling the "write completion" to the user process since the connection requires confirmation from the receiving end of the connection.

The IC Switch routine, in step 534, upon being signaled, obtains the buffer address from the queue and turns control over to the outgoing Transport Layer routine. The outgoing Transport Layer routine, upon taking over control, advances to step 536. In step 536, the outgoing Transport Layer routine obtains the transaction or information unit from the buffer. The routine then advances to step 537 where it generates the next successive outgoing sequence number that will be associated with the information unit (IU).

After the sequence number is generated, the routine advances to step 538 which involves inserting information into the outgoing IC buffer, which information will be part of the header of the information unit. This header information will include the previously generated sequence number and other control information which may constitute, for example, acknowledgement and flow control information for data flowing in the reverse direction over this connection, which control information is piggybacked onto this information unit for conveyance to the other end of the link or connection.

After the control information is inserted into the buffer, the routine advances to decision 539 which determines whether or not end-to-end assurance is required for this connection. In the event that it is required, the routine advances to step 540 and in accordance with this step saves a copy of the information unit and places the IU descriptor or address on an acknowledgement pending queue. The routine then advances to step 541 where an acknowledgement timer is set. As is well known in the art, but not described herein, the saved information unit can, for example, be resent in the absence of receiving an acknowledgement from the other end of the connection prior to the timing out of the timer. After the setting of the timer, the routine advances to step 542.

Alternatively, in decision 539, if end-to-end assurance is not required, the routine advances directly to step 542. In step 542, the buffer address of the information unit (and the header) is placed on the IC queue, the IC Switch routine is signaled to take over control and the Session Layer routine provides a normal return.

In response to the signaling, the IC Switch routine, in step 543 (FIG. 34), obtains the transaction buffer address from the queue and turns control over to the outgoing Network Layer routine. The Network Layer routine, uponn gaining control, advances to step 544 and, in this step, the Network Layer routine proceeds to obtain the information unit from the buffer. The routine then advances to step 545 where the circuit number is obtained from the IU header and the port connection (buffer area) shared with the receiving process is thereby identified. After the identification is made, decision 546 determines whether there is sufficient buffer space in the port between the sending process and the receiving process to accommodate the information unit. In the event that the port is presently busy and the buffer space is inadequate, the routine advances to step 547 wh