Sockets application program mechanism for proprietary based application programs running in an emulation environment

A host data processing system operating under the control of a host operating system such as an enhanced version of the UNIX operating system on a RISC based hardware platform includes an emulator which runs as an application process for executing emulated system (ES) user application programs. The emulator includes a number of emulated system executive service components including a socket command handler unit and a socket library component operating in shared memory and an interpreter, an emulator monitor call unit (EMCU) and a number of server components operating in host memory. The host operating system further includes a host socket library interface layer (API) which operatively connects through a TCP/IP network protocol stack to the communications facilities of the hardware platform. The socket server components operatively connect ES TCP/IP application programs to the socket library interface layer of the host operating system when such application programs issue standard ES socket library calls. The socket command handler unit maps the ES socket library calls into appropriate input/output requests directed to the EMCU. The EMCU directs the requests to an appropriate socket server component which in turn issues the appropriate host socket library calls to the host socket interface layer thereby eliminating both the need to communicate through additional protocol stacks and to provide additional communication hardware facilities.

RELATED PATENT APPLICATIONS 
1. The patent application of Richard S. Bianchi, Dennis R. Flynn, Marcia T. 
Fogelgren, Richard A. Lemay, Mary E. Tovell and William E. Woods entitled, 
"Executing Programs of a First System on a Second System," filed on Sep. 
28, 1993 bearing U.S. Ser. No. 08/128,456 which is assigned to the same 
assignee as this patent application. 
2. The patent application of Richard S. Bianchi, et al. entitled "A Dual 
Decor Capability for a Host System which Runs Emulated Application 
Programs to Enable Direct Access to Host Facilities for Executing Emulated 
System Operations", filed on Sep. 23, 1994, bearing U.S. Ser. No. 
08/311,655 which is assigned to the same assignee as this patent 
application. 
BACKGROUND OF THE INVENTION 
1. Field of Use 
The present invention relates to network communications and more 
particularly to arrangements for executing proprietary application 
programs requiring socket networking services. 
2. Related Art 
With the advent of open system platforms which operate under the control of 
versions of the UNIX* operating system, it becomes more and more desirable 
to be able to efficiently run proprietary application programs on such 
open systems without having to rewrite or port such application programs. 
Also, when certain types of proprietary application programs are written 
to utilize standard communication network protocols, such as TCP/IP, 
implemented as part of the proprietary operating system, this may 
complicate the process of running these programs in an open system 
environment. 
FNT * UNIX is a registered trademark of X/Open Co. Ltd. 
This process is further complicated when multiple instances of an emulated 
system are to be concurrently emulated on an open system platform. This 
type of arrangement is discussed in the related copending patent 
application of Richard S. Bianchi, Dennis R. Flynn, Marcia T. Fogelgren, 
Richard A. Lemay, Mary E. Tovell and William E. Woods entitled, "Executing 
Programs of a First System on a Second System". 
One approach which has been considered is to provide a separate TCP/IP 
protocol stack and separate hardware facilities for servicing the network 
demands of such proprietary application programs. While this approach 
appears satisfactory, it creates considerable processing delays causing 
such proprietary application programs to run too slow thereby reducing 
overall system performance. This can be a substantial disadvantage 
particularly when such programs are to be executed in an emulator 
environment. Also, this approach is too costly in terms of memory 
resources and is unable to take direct advantage of the facilities of the 
open system environment. 
Accordingly, it is a primary object of the present invention to provide a 
method and system which enables application programs running in an 
emulation environment on a host system to be efficiently executed so as to 
minimize delays. 
It is another object of the present invention to provide a method and 
system for executing application programs running in an emulation 
environment on a host system which requires minimal change to the host 
system thereby facilitating debugging, modifying and maintaining of such 
programs. 
SUMMARY OF THE INVENTION 
The above and other objects of the present invention are achieved in a 
preferred embodiment of the present invention which includes a host data 
processing system operating under the control of a host operating system 
such as an enhanced version of the UNIX operating system on a RISC based 
hardware platform. The host system includes an emulator which runs as an 
application process for executing emulated system (ES) user application 
programs. The emulator includes a number of emulated system executive 
service components including a socket command handler unit and a socket 
library component operating in shared memory and an interpreter, an 
emulator monitor call unit (EMCU) and a number of server components 
operating in the host memory. 
The host operating system further includes a socket interface layer which 
operatively connects through a TCP/IP network protocol stack to the 
communications facilities of the host hardware platform. The hardware 
platform operatively couples to conventional network facilities. Socket 
server components operatively connect ES TCP/IP application programs to 
the socket library interface layer of the host operating system in 
response to standard ES socket library calls issued by such programs. The 
socket command handler unit contains specific routines which map the ES 
socket library calls into appropriate input/output requests directed to 
the EMCU which in turn directs the requests to a main socket server 
component. The socket server component in turn issues the appropriate host 
socket library calls to the host socket library interface layer thereby 
eliminating both the need to communicate through additional protocol 
stacks and the need to provide additional communication hardware 
facilities. 
In accordance with the present invention, the main socket server component 
spawns server child processes as a function of the type of socket library 
call function being processed by the server. That is, when the socket 
library call function is determined by the main socket server component to 
be a function/operation requiring either a long or an indeterminate amount 
of time to process, it creates a child process to perform that specific 
operation. This prevents the function from blocking the operation of the 
main socket server component so that it can continue to handle socket 
library calls from other user applications. 
In the preferred embodiment of the present invention, the management of the 
different socket operations being executed is carried out using a socket 
control table. According to the present invention, the socket control 
table contains a number of addressable slot locations which are allocated 
to user applications on a first come first serve basis. The address of 
each assigned slot location is used as an index to the control table for 
obtaining information pertaining to the actual socket (number) assigned by 
the network facilities. The socket control table address is returned to 
the application which issued the library call and is used by the 
application as the assigned socket number. 
Each socket control table slot includes a number of fields which when the 
slot is assigned, store information pertinent to the assigned socket. For 
example, the fields include a first field for storing the actual assigned 
socket number, a second field for indicating the owner/creator of the 
socket entry (i.e. main or child socket server process) and a number of 
fields for storing pipe descriptor information to establish and maintain 
interprocess communications between parent and child socket server 
processes. The control table arrangement enables the efficient 
multiplexing of socket library requests by server components thereby 
increasing overall system performance. The size of the socket control 
table is selected to be large enough to accommodate a substantial number 
of concurrent socket operations. 
Overall, the socket mechanism of the present invention allows proprietary 
application programs running in the emulation environment access to host 
TCP/IP protocol stack communication facilities of the host enhanced UNIX 
operating system thereby eliminating the need to communicate through 
additional protocol stacks or to provide additional communication hardware 
facilities. This in turn enhances overall system performance as well as 
eliminating the need for having to allocate additional system resources 
(e.g. memory).

DESCRIPTION OF THE PREFERRED EMBODIMENT 
FIGS. 1a and 1b collectively form a block diagram of a host system 54 which 
incorporates the components of the present invention. As shown, the system 
54 includes a hardware platform 56 which contains the hardware elements 
such as a central processing unit 58a, a main memory 58b and a number of 
input/output peripheral devices 58c and a communications facility such as 
an Ethernet local area network (LAN) 58d for connecting system 54 to other 
processing systems via standard communication network facilities. 
The central processing unit (CPU) represented by block 58a is a reduced 
instruction set (RISC) based processing unit which takes the form of the 
RS6000 microprocessor manufactured by IBM corporation. The hardware 
platform 56 may also take the form of the DPX/20 system marketed by Bull 
HN Information Systems Inc. 
As seen from FIG. 1a, the hardware platform 56 including processing unit 
58a operates under the control of an enhanced version of the UNIX* 
operating system such as the AIX** operating system. Portions of physical 
memory represented by MEM block 58b are illustrated in terms of the 
layered construction. As shown, memory is divided into two basic levels, a 
user level and an operating system level. The user level is divided into 
emulated system (ES) and host shared memory space and host or an operating 
system kernel native memory space. The shared memory space contains the ES 
executive level 16 which includes a plurality of executive program tasks 
30 spawned by ES executive services components of block 28 for executing 
ES application programs 22 and system administrator programs 24. 
FNT * UNIX is a registered trademark of X/Open Co. Ltd. 
FNT ** AIX is a registered trademark of International Business Machines 
Corporation. 
In the emulated system, each task 30 utilizes a plurality of data control 
structures, such as a task control block (TCB) structure 32, an indirect 
request block (IRB) structure 36, an input/output request block (IORB) 
structure 38 and a resource control table (RCT) structure 40. The task 
control block (TCB) structure 32 contains information pertaining to the 
state of execution of the associated task as well as pointers to interrupt 
save areas for storing hardware parameters related to the task. The 
indirect request block (IRB) structure 36 contains information defining 
the operation requested by an associated task and includes pointers 
identifying the task and its associated task control block (TCB) and a 
pointer to the associated IORB structure. 
The input/output request block (IORB) structure 38 is used as the standard 
means of requesting a physical I/O service. It contains information such 
as a logical resource number (LRN) that identifies the I/O device being 
addressed as well as the location and size of the buffer to be used for 
the transfer and the specific function (operation) requested. The resource 
control table (RCT) structure 40 contains information describing the 
resources, such as its characteristics or information regarding the tasks 
or requests being executed by a corresponding resource as well as pointers 
to its associated task control block (TCB) structure. 
Additionally, two other structures depicted in FIG. 1a are a group control 
block (GCB) structure and a user control block structure of block 29. The 
GCB structure contains information required to define and control the 
operations of a specific task group which defines a named set of one or 
more tasks with a common set of resources within which a user and system 
function must operate. Each group has a two character name (e.g., $L, $S) 
by which the group is uniquely known to the system. The GCB structure 
includes information identifying the lead task whose execution spawns all 
other tasks required for executing group programs. As indicated, the GCB 
structure includes a number of user control blocks (UCB), each of which 
contains information defining the user's personality such as user node 
identification, user group id within a node, user task id within group, 
user person id and pointer information to directories to which the user 
has access. 
As shown, the emulated system utilizes a further data structure 
corresponding to system control block (SCB) structure 27. This data 
structure is created at system startup and contains information defining 
system resources and pointers to the different task groups established by 
the system represented by a corresponding number of group control blocks 
in the system. For further information regarding such structures and their 
relationships to each other, reference may be made to U.S. Pat. No. 
5,111,384 and the publication entitled "HVS PLUS Systems Concepts" 
published by Bull HN Information Systems Inc., Order No. HE03-01. 
As indicated in FIG. 1b, the shared memory space further includes a memory 
queued interface (MQI) represented by block 84 which provides a form of 
interprocess communication mechanism and a software active queue (SAQ) of 
block 88. SAQ block 88 represents a data structure used to provide the 
path by which the results of the operations performed by the kernel level 
components are passed back or returned by the host processes to the 
requesting emulated system user level tasks 30 being executed. Thus, it 
can be viewed as functioning as an output stage of MQI 84. This data 
structure is similar to data structures which are used by the emulated 
system operating system. 
MQI block 84 is a semaphore data structure which takes the form of a single 
linked list controlled by semaphores through a set of routines which are 
executed by the various host processes operating within different levels 
or layers that want to communicate with each other. Its routines are used 
to manage queues within the pseudo device drivers 74 and the software 
active queue 88. 
Executive Services Components 28 
As seen in FIG. 1a, the executive services components 28 of executive layer 
16 includes a plurality of components or facilities which are equivalent 
to those facilities normally included in emulated system. The emulated 
system is a multiprogrammed multiprocessor system. The facilities 
illustrated in FIG. 1a include a listener module 280, a file management 
facility 282, a socket monitor call command handler unit 284, and an ES 
socket library 286 which are arranged as shown. The listener module 280 is 
responsible for monitoring the operations of terminals configured for 
login and for initiating user tasks in response to user commands. As 
indicated in FIGS. 1a and 1b, listener module 280 runs as a task 30 with 
its own set of unique data structures. 
The listener module 280 is able to consult a profiles file containing user 
specific registration information such as user id, login id and password 
requirements tabulated by the system administrator for all registered 
users. The listener module 280 checks the user profile when monitoring the 
privileges and/or restrictions given to each user. The file management 
facility 282 includes the conventional shared data structures and set of 
routines normally provided to perform functions that access such data 
structures to control the synchronization of concurrent processes or tasks 
in addition to performing various system services or functions. That is, 
the facility responds to system service monitor calls identifying the 
types of services requested (e.g. creating or deleting files, reading or 
writing records or blocks in files) which result in the specified system 
services being executed by the emulated system on behalf of executing user 
application programs. 
A monitor call unit (not shown) receives monitor calls from the interpreter 
component 72 which are in turn to be executed interpretively using the ES 
executive service components of block 28. A command handler unit (not 
shown) contains the routines that respond to user commands entered via a 
terminal or program. In response to such commands, the command handler 
unit routines invoke the appropriate tasks for executing such commands. 
The present invention includes an ES socket command handler unit 284 and ES 
socket library 286. The ES socket library 286 is constructed to provide 
the same socket application program interface (API) as provided in the 
emulated system. This interface is described in detail in the manual 
entitled "GCOS 6 HVS TCP/IP SOCKET API FOR C USERS" published by Bull HN 
Information Systems, Inc., copyright 1993, order no. RD89-00. 
The ES socket command handler unit 284 contains a plurality of routines 
which operate to convert HVS socket calls into the appropriate low level 
request input/output (RQIO) monitor calls accompanied by IORBs created by 
mapping/translating the socket library calls into the corresponding socket 
function codes. As described in detail herein, the IORBs are forwarded to 
the main socket server component by the EMCU via the MQI interface. The 
main socket server component then issues the appropriate host (ADO socket 
calls to the host system socket facilities. 
Emulator level layer 68 
As indicated in FIGS. 1a and 1b, the next layer within the user level is 
the emulator executive level 68. This level includes certain components 
present in the emulated system which have been transformed into new 
mechanisms which appear to the remaining unchanged components to operate 
as the original unchanged components of the emulated system. At the same 
time, these new mechanisms appear to the components of the kernel level 64 
as native components with which the host system is accustomed to operate. 
As shown, the components include the interpreter 72, an emulator monitor 
call unit (EMCU) 73, dynamic server handler (DSH), main socket server 
component 98, a number of child socket processes 96 and a socket control 
table 94 operatively coupled together as shown. 
As indicated in FIG. 1b, the emulator executive level 68 further includes a 
plurality of pseudo devices drivers (PSDD) 74 for each input/output device 
or type of input/output device which is required to be emulated by host 
system 54. For example, the pseudo device drivers 74 will include PSDDs 
for terminals, disk drivers, tape drivers, displays and for certain 
communication devices. 
For a more detailed discussion of other aspects of the SAQ 88, MQI block 
84, PSDD 74 and other emulator components, reference may be made to the 
related patent application. 
The interpreter 72 successively fetches the instructions of an emulated 
system application program, categorizes each instruction and executes it 
interpretively through sequences of RISC instructions which allows CPU 
58a, MEM 58b and other elements of host system 54 to emulate the 
operations of corresponding elements of the emulated system. The 
interpreter 72 includes a monitor call (MCL) table containing information 
for each possible monitor call which it utilizes to determine whether to 
trap or send an ES monitor call to the ES executive services components 28 
for execution of the instruction or to make an emulator call to EMCU 73 
for execution of the instruction through the services of an appropriate C 
language routine (server). The EMCU 73 is responsible for acquiring from 
the host system 54, the necessary memory and other resources, for 
initializing the emulated system data structures and invoking interpreter 
72 and the various server processes. Both the interpreter 72 and EMCU 73 
run as host processes. 
As viewed by the host system, the ES service components 28 and tasks 30 
being executed on behalf of the application programs, the interpreter 72 
and EMCU 73 are executed in the system 54 of FIGS. 1a and 1b as a single 
process 80 wherein such process corresponds to one or more user processes 
as defined by the conventions of the host operating system being run on 
host system 54. Thus, it is possible to have multiple instances of the 
emulated system concurrently emulated on host system 54. 
The dynamic server handler (DSH) 92 is created by EMCU 73 during 
initialization. The server 92 communicates with emulated system processes 
through MQI 84 as indicated. The lower level main socket server 98 and 
socket control table 94 are dynamically created by higher level server 92 
for carrying socket operations according to the present invention. The 
main socket server 98 creates child socket processes as a function of the 
type of socket operation to be performed and manages such child processes 
through socket control table 94. All of the servers operate as root and 
therefore have super user privileges with access to any file within the 
host system 54. 
The server 92 include mechanisms specifically designed for validating 
security at the user level in conjunction with the execution of dual decor 
commands and functions. These mechanisms are described in the related 
copending patent application entitled "A Dual Decor Capability for a Host 
System which runs Emulated Application Programs to Enable Direct Access to 
Host Facilities for Executing Emulated System Operations". 
Operating System/Kernel Level 
The operating system/kernel level 64 includes the standard mechanisms and 
components normally included within the host operating system. As shown, 
level 64 includes a kernel process manager component 70 and a number of 
host kernel I/O services (KIOS) processes 66 for each pseudo device driver 
(PSDD) 74 which is to be emulated by the host system. Additionally, in the 
preferred embodiment of host system 54, level 64 is assumed to contain the 
standard utility programs, shell, editors, compilers, etc. and libraries 
(e.g., I/O libraries, open, close) which are accessed in the host user 
mode. For further information regarding the use of such arrangements, 
reference may be made to publications of the IBM Corporation describing 
the AIX operating system. 
In the preferred embodiment, the kernel/operating system level 64 further 
includes as an interprocess communications facility, an implementation of 
"sockets" which includes a host sockets library 97 for storing a plurality 
of socket subroutines and network library subroutines and a TCP/IP network 
protocol stack facility 99 arranged as shown. The stack facility 99 
connects to an Ethernet driver included within kernel level 64 (not shown) 
which communicates with the Ethernet LAN 58c. 
As indicated in the system of FIGS. 1a and 1b, as in the case of the AIX 
operating system, the socket subroutines contained in host sockets library 
97 serve as the application program interface (API) for TCP/IP. This API 
provides three types of communications services which use different 
components of TCP/IP. These are reliable stream delivery, connectionless 
datagram delivery and raw socket delivery. For further information 
regarding sockets, reference may be made to various well known 
publications and texts such as publications of IBM Corporation describing 
the AIX Version 3.2 for RISC System/6000 and the text entitled "UNIX 
System V Release 4: An Introduction for New and Experienced Users" 
published by Osborn McGraw-Hill, Copyright 1990 by American Telephone and 
Telegraph Company. 
DESCRIPTION OF OPERATION 
In the emulated system, several different types of applications included 
within block 22 issue ES socket library calls to carry out read and write 
operations between the host and remote computer systems using TCP/IP. In 
the preferred embodiment, these applications include an FTP interactive 
program which allows a user to transfer files between the system of FIGS. 
1a and 1b and a remote system; a Telnet interactive program which 
implements the UNIX remote terminal logon and a remote file access (RFA) 
which gives a user access to the facilities of a remote system. For 
specific information about these types of applications such as FTP, 
reference may be made to the publication entitled "GCOS 6 HVS TCP/IP 
Reference Manual" published by Bull HN Information Systems Inc., copyright 
1993, Order Number RE86-01. 
With reference to FIGS. 1a through 4b, the operation of the preferred 
embodiment of the socket mechanism of the present invention will now be 
described. In this example, it is assumed that reliable stream delivery 
services are used. By way of example, it is assumed that one or more of 
the above emulated system application programs 22 written to run on a 
DPS6000 system under the GCOS6/HVS operating system are being executed in 
the emulation environment provided by the system of FIGS. 1a and 1b. 
Therefore, the system of FIGS. 1a and 1b has been initialized to run the 
emulator 80 and that the application programs 22 are running and have 
initiating communications with the remote computer system. Since the 
typical flow of events for a connection oriented transfer using sockets is 
well known, the networking aspects of establishing such connections will 
not be described in detail herein. For further information regarding such 
events, reference may be made to the text entitled "Unix Network 
Programming" by Richard Stevens, published by Prentice-Hall, copyright 
1990. 
Overall Description-FIG. 2 
With reference to FIG. 2, the overall operation of the socket mechanism 
will now be described. In using the socket interface, an application 
program invokes a socket function (block 200) which is typically processed 
as indicated in FIG. 2. More specifically, the application program 22 
invokes the socket function by issuing a socket library call which is 
directed to socket library 286. Depending upon the type of application 
program, the library call may be issued directly or indirectly via the 
file management component 282. But whatever the path, the result is that a 
ES library call is applied as an input to ES socket library 286. 
In response to the library 286 call, the ES socket library 286 directs a 
monitor call to the executive (MCL) handler unit which is in turn directed 
to the appropriate socket handler routine (block 202). This routine 
associates the socket to the HVS file (block 204) via the file management 
unit 282. Next, the socket handler routine maps the ES socket monitor call 
to an IORB in accordance with the present invention as described herein 
(block 206) and then issues an request I/O (RQIO) which includes that 
IORB. 
As indicated in FIG. 2, the RQIO request is forwarded to the socket server 
98 for processing. The socket server 98 obtains the request by reading an 
assigned MQI socket queue (block 208) as described herein. It examines the 
IORB and determines from the device specific word (dvs) containing the 
actual socket library call if the function/operation specified in the call 
is a blocking function. That is, it determines if the socket operation 
will require substantial time to execute so as to prevent socket server 98 
from responding to socket function requests issued by other application 
programs 22 thereby impairing system performance. If it is not a blocking 
function (block 210) (i.e., will not incur substantial delay), then socket 
server 98 performs the designated socket operation (block 212) using the 
host TCP/IP facilities 99, posts the IORB and returns control back to the 
handler/user application program (block 214). 
In the case where the operation is a blocking function, then socket server 
98 spawns or creates a separate child process (block 216) to perform the 
socket operation on the host system (block 218). When the operation is 
completed by the child process, it posts the IORB and returns control back 
to the user application program via the socket handler (block 220). The 
spawned child process remains active/alive for the duration of the socket 
(i.e. until the socket is closed). 
Detailed Description of Socket Functions 
With particular reference to FIGS. 3a through 3c2, the manner in which the 
socket mechanism of the present invention operates to process different ES 
socket function system calls will now be described. FIG. 3a illustrates 
the operations pertaining to the open socket function. As indicated, this 
operation is initiated in response to an ES monitor call command code of 
3800. The socket function is used by either a client or server application 
program to create or open a socket for establishing an end point for 
communicating with a remote computer system. 
The open socket function has the format: int socket(int Family, int Type, 
int Protocol). In the system of FIG. 1, the arguments Family, Type and 
Protocol are set to specify AF.sub.-- INET SOCK.sub.-- STREAM or 
SOCK.sub.-- RAW or SOCK.sub.-- DGRM, and 0 respectively. 
The socket function is applied as an input to the ES socket library 286 and 
results in the generation of the MCL 3800 monitor call as in the emulated 
system. This ensures that application program 22 sees the same interface 
in FIG. 1 as in the emulated system. The MCL 3800 monitor call is applied 
to the socket monitor call handler unit 284 which locates the 
corresponding function as indicated in block 202 of FIG. 2. As in the 
emulated system, the major function code high order byte value "38" 
through a first level table branching operation causes control to be 
passed from the executive MCL handler to the TCP/IP MCL handler of block 
284. Using the minor function code low order byte value "00" contained in 
the MCL 3800 monitor call, the TCP MCL handler via a second level table 
branching operation locates the appropriate socket handler routine which 
in the instant case is "socket". 
The socket handler routine performs several operations which are similar to 
those performed by ES components within the system being emulated. These 
operations include the operations of blocks 302 through 306 of FIG. 3a. 
More specifically, the socket handler unit 284 allocates a "socket 
structure" for a file control block (FCB) data structure, creates the FCB, 
seizes it and obtains a logical resource number (LRN). These operations 
are carried out through the file management unit 282 in a conventional 
manner. 
Next, in accordance with the teachings of the present invention, the socket 
handler routine "maps" the reel to IORB by building the IORB extended 
structure with the socket parameters/arguments contained in the ES open 
socket call (block 308). In greater detail, this is done by performing a 
memory set operation wherein the ES socket function arguments Family, Type 
and Protocol are placed into specific fields (iorb.so.socket.family, 
iorb.so.socket.type and iorb.so.socket.protocol) within the extended 
portion of the IORB data structure. Also, the socket function code (i.e. 
open socket) is placed in the device specific word (dvs) of the IORB. 
Since this is an open socket function, the socket handler unit 284 first 
obtains a logical resource number (LRN) for the socket. To do this, socket 
handler unit 284 issues to EMCU 73, a special ES executive handler monitor 
call (MCL.sub.-- SOCK.sub.-- LRN) containing a command code of hexadecimal 
0x3727. The EMCU 73 obtains the socket LRN and resource control table 
(RCT) entry which is to be used in communicating with main socket server 
98. More specifically, an area of shared memory is reserved for a given 
number of RCT/TCB structure pairs which are dynamically allocated for 
handling commands and functions. All of the RCTs are linked together onto 
a free queue. The 3727 monitor call is used to request a socket LRN and 
removes an RCT/TCB pair from the free queue. Next, the EMCU 73 allocates 
the socket LRN and RCT for subsequent use by the main socket server 98. 
Next, the socket command handler 284 generates the I/O request (RQIO) 
specifying a CONNECT operation for issuance to the socket server 98. The 
IORB containing the socket parameters has a number of fields which are 
initialized to the appropriate values for carrying out the socket 
operation. This includes having its LRN field set to the extended LRN 
value previously obtained for the main socket server 98 and its function 
code to specify the CONNECT, the operation type field set to SOCK.sub.-- 
IORB.sub.-- ID indicating that it belongs to the socket and information to 
specify the type of socket function to be performed by server 98. More 
specifically, a "11" socket operation code is included in the device 
specific word (dvs) of the IORB to specify the create or open socket 
function. 
Since this is the first RQIO monitor call and the RCT entry corresponding 
to its LRN indicates that no server process has yet been created, the EMCU 
73 enqueues the IORB onto the MQI queue section (socket queue) of the 
dynamic server handler (DSH) 92. In response to the RQIO monitor call, the 
DSH 92 determines from the IORB that it is associated with a socket 
operation and that it contains a CONNECT function code. 
The DSH 92 takes the required steps to establish a connection between the 
application program/handler unit 284 component issuing the socket call and 
the main socket server 98. This involves issuing host system calls to the 
kernel manager 70 in the form of a fork system call which creates a new 
host process and an exec system call which invokes the main socket server 
98 to be run by the new host process. Also, DSH 92 creates a main socket 
server and MQI queue pair and establishes a connection to the RCT so that 
EMCU 73 can enqueue subsequent socket requests to this LRN on the 
appropriate server queue. Following the creation of main socket server 98, 
DSH 92 calls the server 98 with a number of required parameters, some of 
which are used to allocate system shared memory to read/write IORBs, 
buffers etc. and to attach shared memory for socket table(s). 
Creation of Socket Control Table Structure 
The main socket server 98 creates an addressable socket control table 
structure 94 in host system space as part of the initialization function. 
The socket control table structure 94 is shown in detail in FIGS. 4a and 
4b. The table 94 is set up to have a size of addressable 1024 slots or 
locations for storing information pertaining to a number of sockets. The 
first three address slots of FIGS. 4a and 4b are reserved for convenient 
storage. Thus, the socket address values start with an index value of "3". 
As indicated in FIGS. 4a and 4b, each of the socket locations contains the 
following fields: sockno, sock.sub.-- pid, sock.sub.-- pid.sub.-- xmit, 
sock.sub.-- flags, sock.sub.-- wrpipefd, sock.sub.-- xwrpipefd, 
sock.sub.-- clspipefd0 and sock.sub.-- clspipefd1. The sockno field is 
used to store the actual or real socket number returned by the host tcp/ip 
facility 99. This is done to prevent issuing duplicate sockets/processes 
for handling application program requests. 
The sock.sub.-- pid field is used to store the process ID of the child 
process executing an accept0, recv0 or recvfrom0 socket operation. The 
sock.sub.-- pid.sub.-- xmit field is used to store the process ID of the 
child process executing a send0 or sendto0 socket operation. 
The sockflags field stores a number of indicators which include a 
main.sub.-- sock indicator flag whose state indicates the owner of the 
socket (state=1, socket owned by main server 98, state=0, socket owned by 
child server process), an in.sub.-- accept indicator whose state indicates 
when the socket is in an accept block state and an in.sub.-- rcvbi 
indicator whose state denotes when a break-in has been received. These 
last two indicators specify the state of the socket and enable an orderly 
shut down of the socket operation (i.e. return/release 13 of ES and host 
resources) when required such as when the ES file management unit 282 
issues an abort group (AGR) command to close the socket. 
The next three fields are used for carrying out interprocess communications 
(IPC) between parent and child processes. The sock.sub.-- wrpipefd field 
is used to store the parent process write pipe file descriptor used for 
communicating with the child process executing the recv0, recvfrom0 or 
accept0 socket as well as other socket library calls. The sock.sub.-- 
xwrpipefd field is used to store the parent process write pipe file 
descriptor used for communicating with the child process executing the 
send0 or sendto0 socket operation. The sock.sub.-- clspipefd0 & 1 fields 
are pipe descriptor number information indicating which pipe resources are 
to be returned to the host system when the socket is closed. 
The main socket server 98 initializes the required ES system data 
structures (e.g. SCB, NCB) and the socket control table pointers (i.e. 
initial, current and sockmax) used to access socket control table 94 to 
the appropriate initial values. The server 98 also issues a host kernel 
call to obtain its process ID. 
Then, the main socket server 98 begins a dispatch loop wherein it reads the 
common socket server's MQI queue. From the queue, it obtains the IORB and 
then obtains the socket MCL command code from the device specific word 
(dvs) of the socket extended IORB. The socket server 98 uses the socket 
MCL command code value to branch to the appropriate routine for carrying 
out the specified socket function. Since the socket function previously 
mapped into the IORB specified a socket function (MCL 0x3800), the main 
server 98 references a routine mcl-socket for creating a communication 
endpoint. That is, as indicated in block 310 of FIG. 3a, the socket server 
98 issues a host socket call (socket0) to host sockets library 97 using 
the parameters contained in the extended IORB (family, type, protocol). 
The host library component 97 invokes the host TCP/IP network protocol 
stack facility 99 which initiates in a conventional manner, the 
appropriate series of operations for obtaining the actual socket number 
from the TCP/IP network facility. As indicated by block 312, the server 98 
determines if it received a socket number. When it has received a socket 
number, it then finds the first unused slot in the socket control table 94 
by accessing the table with the socket current table pointer. It then 
stores in the sockno field of the slot, the descriptor value returned by 
the TCP/IP stack facility 99 which corresponds to the actual socket number 
(block 316 of FIG. 3a). It also sets the main.sub.-- sock indicator flag 
of the slot for indicating that the socket is owned by the socket server 
98. 
Since this is the first socket operation, the slot location identified by 
an address (index) of 3 is the first available slot in socket control 
table 94. It is this value that is returned to the user application 
program as the socket while the actual socket descriptor (actual socket 
number) remains stored in the sockno field of slot 3. As indicated in 
block 318 of FIG. 3a, server 98 stores the address index value 3 in the 
dv2 field of the IORB structure and terminates the RQIO by posting the 
IORB with good status (block 318). If no actual socket was obtained, then 
socket server 98 terminates the RQIO and returns error status (block 314). 
As indicated in block 320 of FIG. 3a, control is returned to the socket 
handler 284 which saves the socket descriptor (index value of 3) in the 
socket FCB structure (block 320) and issues a call to file management unit 
282 to release the socket FCB data structure. The file management unit 282 
in response to the call locates the socket FCB, marks it not busy and 
decrements the FCB usage count by one and performs any other operations 
required for freeing up the FCB structure. As indicated in block 322, the 
socket descriptor index value of 3 is returned to the user application 
program. This completes the processing of the open socket function. 
Accept Function-FIGS. 3b1 and 3b2 
FIGS. 3b1 and 3b2 illustrate the series of operations performed by the 
socket mechanism of the present invention in processing an accept 
function. As well known in the art, the accept function is used by a 
server application program for accepting a connection on a socket and 
creating a new socket. The accept function of the preferred embodiment has 
the format: 
EQU #include &lt;socket.h&gt; 
EQU int accept (Sd, Name, Namelen) 
EQU int Sd; 
EQU struct sockaddr *Name; 
EQU int *Namelen. 
Name is a result parameter that is filled in with the address of the 
connecting entity, as known to the communications layer and Namelen is a 
value result parameter which on return contains the actual length in bytes 
of the address returned. The argument/parameter Sd is a socket that has 
been created with the previously discussed socket function, bound to an 
address by a bind function, and is listening for connections after a 
listen function. 
The accept function takes the first connection request on the queue of 
pending connection requests, creates a new socket with the same properties 
of Sd and allocates a new socket descriptor for the socket. If there are 
no connection requests pending on the queue, this function blocks the 
caller application until one arrives. The application program uses the 
accepted socket to read and write data to and from the socket which 
connected to this socket and is not used to accept more connections. The 
original socket Sd remains open for accepting further connection requests. 
As indicated in FIG. 3b1, the application program 22 applies the accept 
function as an input to the ES socket library 286 and results in the 
generation of the MCL 3801 monitor call as in the emulated system. The MCL 
3801 monitor call is applied to the socket monitor call handler unit 284 
which locates the corresponding function. In the same manner described 
above, the MCL 3801 value is used to locate the appropriate socket handler 
routine which in this case is "accept". 
As indicated in FIG. 3b1, the accept socket handler routine performs the 
operations of blocks 332 through 338 which associate the required sockets 
to the HVS file. More specifically, the accept handler routine finds the 
socket FCB, increments the socket FCB reference and usage counts and gets 
the socket descriptor (block 332). Also, the accept handler routine 
creates another socket FCB with the same properties as the pending socket 
and allocates a socket structure for the FCB (blocks 334 and 336). These 
operations are carried out through the file management unit 282 in a 
conventional manner. 
As indicated in block 338, in accordance with the teachings of the present 
invention, the accept handler routine maps the mcl to IORB by building the 
IORB extended structure with the accept parameters contained in the accept 
socket call (block 338). In greater detail, this is done by performing a 
memory set operation wherein the accept function arguments are placed into 
specific fields (iorb. so.accept.newlrn) within the extended portion of 
the IORB data structure. Also, information is included to identify that 
the IORB data structure belongs to a socket and to specify the type of 
socket function to be performed by server 98. More specifically, a "1" 
function code is included in the IORB data structure to specify that the 
socket function is an accept socket function. 
When building of the IORB data structure is completed, the accept handler 
routine generates a RQIO request specifying a WRITE operation for issuance 
to socket server 98. The IORB containing the socket accept parameters has 
a number of fields which are initialized to the appropriate values in the 
same manner as described above for carrying out the accept operation. The 
RQIO request is issued to EMCU 73 which after determining from the LRN 
value that the socket server process has been created, enqueues the IORB 
onto the socket server MQI queue for processing. 
The socket server 98 process upon receipt of the request IO and upon 
determining that it is an accept operation, performs the series of 
operations in block 340 of FIG. 3b1. That is, first, the socket server 
creates interprocess communications (IPC) channel with the later spawned 
child process 96 by issuing a pipe system call (pipe(pipefd) to the kernel 
70. The kernel 70 opens up a PIPE and returns read and write file 
descriptors to communicate with the later spawned child process. 
In accordance with the teachings of the present invention, since the accept 
socket operation requested requires a substantial amount of time to 
complete, the socket server 98 spawns child process 96 to handle the 
operations for processing the accept function so as not to tie up or 
prevent (block) the socket server 98 from responding to other application 
IORB socket requests. This is done by the server process 98 issuing a 
standard fork system call (fork0)to the kernel 70 which creates the new 
process which is a logical copy of the parent server process except that 
the parent's return value from the fork is the process ID of the child 
process and the child's return value is "0". 
As indicated by block 342 of FIG. 3b1, the parent socket server process 98 
returns to process the next incoming socket IORB. The child process 96 
begins initial processing by executing the operations of block 344. As 
indicated, the child process 96 first locates the slot entry (i.e. index 
of 3) in the socket control table 94 for the file descriptor provided as 
an argument by the IORB and stores the child process in the sock.sub.-- 
pid field of the entry for subsequent proper closing of the socket. Also, 
the child process 96 marks the socket as being in the accept blocked state 
by setting the in.sub.-- accept indicator flag to the appropriate state. 
This enables the server to break-in and stop the operation. 
As indicated by block 346, the child process 96 generates a system call to 
the host sockets library 97 using the previously assigned socket number 5 
(i.e., ns=accept(realsock, peer, (int*)intp) for obtaining a new socket 
for the incoming socket connection. This initiates the appropriate series 
of operations for obtaining an actual socket number. 
The child process 96 loops waiting for the return of the actual socket 
number from the TCP/IP stack facility 99. If there is an error, the result 
is that an error is entered into the device status word of the IORB data 
structure and the RQIO operation is terminated (block 350). Assuming that 
there was no error, the child process 96 performs the series of operations 
of block 352. As indicated, the child process 96 resets the state of the 
in.sub.-- accept indicator flag in the third slot of the socket control 
table 94 corresponding to index value of 3 in addition to saving the child 
process ID (pid) in the sock.sub.-- pid field of that slot. 
Next, the child process 96 finds the next unused slot in the socket control 
table 94 which corresponds to the slot location having an index of 4 by 
accessing the table with the socket current pointer value after being 
incremented by one. It then stores in the sockno field of the slot, the 
descriptor value returned by the TCP/IP stack facility 99 which 
corresponds to the actual socket number (e.g. 100). It also sets/verifies 
that the state of the main.sub.-- sock indicator (i.e. "0") designates 
that the socket is owned by the child process. Also, it saves the child 
process ID in the sock.sub.-- pid field of the slot having the index of 4. 
At this point, there are two slots which contain the pid of the child 
process 96. It will be noted that while the child process started with the 
slot having index of 3 in socket control table 94, it now is operating 
with the slot having an index of 4. While this example uses sequentially 
numbered slots, it will be appreciated that the slot to which the child 
process 96 sequences may be any slot within the socket control table 94 
which corresponds to the next available slot location. 
As indicated by block 352 of FIG. 3b2, the child process 96 stores 
previously obtained pipe descriptor value into the sock.sub.-- wrpipefd 
field of the slot having an index of 4 for communicating between the child 
process 96 and server process 98 as required for processing subsequently 
issued socket commands. As indicated by block 354, the child process 96 
next stores the address index value 4 which corresponds to the new socket 
table descriptor into the dv2 field of the IORB status word. It also 
terminates the RQIO operation by posting/returning a good status 
indication. 
As indicated in block 356 of FIG. 3b2, the child process 96 enters a socket 
services loop and waits for further commands to be received via the IPC 
which involve the new socket. As a consequence of terminating the RQIO 
operation, control is passed back to the socket handler which carries out 
the operations of blocks 358 through 364 which completes the accept 
operation. As indicated, block 358 involves the allocation of an LRN for 
the accept operation. As discussed above, to do this the socket handler 
unit 284 issues to EMCU 73, a special ES executive monitor call 
(MCL.sub.-- SOCK.sub.-- LRN) containing a command code of 0x3727. The EMCU 
73 obtains the socket LRN and resource control table (RCT) entry which is 
used in communicating with main socket server 98 in the manner described 
above. Next, the socket handler performs a series of operations which 
results in issuing another RQIO request to perform an accept.sub.-- 
confirm operation (block 362) for registering the new socket number 
corresponding the index of 4 and the RCT associated therewith. These 
operations include building the IORB involving taking the new socket value 
sockfd, placing it into the field of the IORB (iorb.so.accept.sockfd) and 
then generating the RQIO specifying a CONNECT including the IORB 
containing a socket function code specifying an accept.sub.-- confirm 
operation. 
The RQIO request is issued to the EMCU 73 which carries out the required 
operations for registering the new socket number in the RCT. When the 
accept.sub.-- confirm IORB is completed, the socket handler also saves the 
socket descriptor which is associated with the new LRN and releases the 
socket FCB through the file management unit 282 in the manner previously 
described (block 364). The socket descriptor is returned to the 
application program 22 which is now able to proceed with its operation. 
FIGS. 3c1 and 3c2 
FIGS. 3c1 and 3c2 illustrate the series of operations performed by the 
socket mechanism of the present invention in processing a socket receive 
function/system call issued by an ES application program. The receive 
function is used to receive data from another socket. The receive (recv) 
function of the preferred embodiment has the format: 
EQU #include &lt;socket.h&gt; 
EQU int recv (Sd, Buf, Len, Flags) 
EQU int Sd 
EQU void *Buf; 
EQU int Len, Flags. 
Sd is a socket descriptor that has been created with the socket function, 
Buf is a pointer to buffer, Len is the number of bytes to receive and 
Flags indicates optional information. The receive function attempts to 
read Len bytes from the associated socket into the buffer pointed to by 
Buf. If no messages are available at the socket, the receive function 
waits for a message to arrive. 
As indicated in FIG. 3c1, the application program 22 applies the receive 
function as an input to the ES socket library 286 and results in the 
generation of either an MCL380a or MCL3808 monitor call as in the emulated 
system. The monitor call MCL380a is generated for a recv0 function for 
receiving a message from a socket while monitor call MCL3808 is generated 
for a recvfrom0 function which is also used to receive data from another 
socket whose destination may be specified rather than being implicitly 
specified by the connection as in the case of the recv0 function. It will 
be assumed that the monitor call generated is for the recv0 function. 
The MCL380a monitor call is applied to the socket monitor call handler unit 
284 which locates the corresponding function. That is, in the same manner 
described above, the MCL380a value is used to locate the appropriate 
socket handler routine which in this case is "recv". As indicated in 
blocks 380 and 382 of FIG. 3c1, the recv handler routine finds the socket 
FCB, increments the socket FCB and usage counts and gets the socket 
descriptor (block 380). These operations are carried out through the file 
management unit 282 in a conventional manner. 
As indicated in block 382, the reev handler routine builds the IORB 
extended data structure with the recv parameters contained in the recv 
socket system call. In greater detail, this is done by performing a memory 
set operation wherein the recv function arguments are placed into specific 
fields (iorb. so.data.flags) within the extended portion of the IORB data 
structure. Also, information is included in the IORB identifying that it 
belongs to a socket and specifying the type of socket function to be 
performed by server 98. More specifically, a "0x0f" is included in the 
IORB data structure to specify the socket function as a recv socket 
function. 
When the building of the IORB data structure is completed, the recv handler 
routine generates a RQIO request specifying a READ operation for issuance 
to socket server 98. The IORB containing the socket recv parameters has a 
number of fields which are initialized to the appropriate values in the 
same manner as described above for carrying out the recv operation. The 
RQIO request is issued to EMCU 73 which after determining from the LRN 
value that the socket server process has been created, enqueues the IORB 
onto the socket server MQI queue for processing. 
The socket server process 98 upon receipt of the request I/O performs the 
operations of block 384. That is, it translates the HVS address arguments 
from the ES system space into host space as required. Using the IORB 
socket descriptor index value, the server process 98 locates the socket 
control table slot specified by that socket descriptor. The socket server 
process 98 then determines if a child process exists for the socket (block 
386) by examining the indicator flag main.sub.-- sock of the slot. If the 
sock.sub.-- pid and main.sub.-- sock indicator flag are set to values 
indicating that a child process already exists, then the server process 98 
performs the operations of block 388. This involves obtaining the IPC pipe 
descriptor stored in the sock.sub.-- wrpipefd field of the slot identified 
by the index value, setting up a message buffer for the operation and 
sending a message to the child process via the IPC pipe. Also, the server 
process 98 returns to process the next available IORB request. 
If the sock.sub.-- pid equals the child pid or "0" and main.sub.-- 
indicator flag is set to a value indicating that no child process exists, 
then the socket server process 98 performs the operations of block 390. 
That is, the socket server process 98 creates an interprocess 
communications (IPC) channel for use with the later spawned child process 
by issuing a pipe system call (pipe(pipefd)) to the kernel 70. The kernel 
70 opens up a PIPE and returns read and write file descriptors to 
communicate with the child process. 
In accordance with the teachings of the present invention, since the 
requested socket recv operation requires substantial time to complete, the 
socket server 98 spawns the child process to handle the operations for 
processing the receive function so as not to tie up or block socket server 
98 from responding to other socket requests (block 392). The socket server 
process 98 then returns to process the next available IORB request. 
Next, the spawned child process enters a socket receive routine (sorecv) 
which reads the newly requested socket operation (message) contained in 
the IPC pipe (block 394) using read file descriptor pipefd0!. It checks 
for the presence of an ioctl command specifying a break-in. Assuming that 
the IPC pipe contains no ioctl command, the child process issues a socket 
receive library call to the host system. That is, the child process issues 
the socket receive (recv0) call to the host socket library (block 402) 
which contains the actual socket number obtained from socket control table 
94. 
Next, the child process enters a receive loop wherein it determines if the 
receive is completed at which time it sends back the data to the ES 
application and if the data was correctly received (block 404). If it was, 
the child process terminates the receive RQIO and posts the IORB with good 
status (block 406). As indicated in FIG. 3c2, the child process following 
the completion of the first receive again performs another read PIPE 
operation and processes the next receive request. Thus, the child process 
continues to handle receive requests on that socket until the socket is 
closed. Accordingly, there may be a series of receive socket requests 
issued before the child process receives a ioctl command specifying a 
break-in. If the child process receives such a command, it performs the 
operations of blocks 398 and 400. It terminates the receive socket 
operation taking place at that time according to the state of the 
in.sub.-- rcbi indicator in the flags field of the socket control table 
slot associated with the socket. It then terminates the RQIO request and 
posts good status in the IORB (block 398). 
From the above, it is seen that the socket mechanism of the present 
invention performs an ES socket library receive function by spawning a 
child process which prevents blocking socket server process 98. Through 
the use of socket control table 94, the socket server process 98 is able 
to communicate and efficiently manage the operations of the child process 
which in turn communicates with the host library and TCP/IP network 
protocol stack facilities. 
The other i/o socket functions not described (e.g. bind, listen, close, 
send, etc.) are processed in a manner similar to the above described 
socket functions. It will be appreciated that the non-blocking bind and 
listen socket functions typically are processed by server process 98 since 
they do not require a substantial amount of time to process. It will be 
appreciated that a child process can also execute bind or listen socket 
functions (i.e., in the case of an accept). The send socket function 
similar to the receive function requires a substantial amount of time and 
therefore processed by a spawned child process to allow the server 98 
process socket library calls received from other application programs. 
Thus, as graphically indicated in FIGS. 4a and 4b, there may be a plurality 
of child processes being concurrently managed by the server 98 issuing 
socket library calls to the host networking facilities thereby enabling 
the socket mechanism of the present invention to efficiently service a 
plurality of application programs. Thus, independent of the type of socket 
function being performed by a particular emulated system application 
program being executed, the socket mechanism of the present invention 
processes socket library calls in an efficient manner. 
For further more specific details regarding the implementation of the 
socket mechanism of the present invention, reference may be made to the 
source listings contained in the attached appendix which include the 
following items: Main Socket Server Component; Socket Handler Component; 
Socket Control Table Structure; Socket Call and IORB Related Data 
Functions; and Socket Control and Related Data Structures. 
It will be apparent to those skilled in the art that many changes may be 
made to the preferred embodiment of the present invention. For example, 
the present invention is not limited to the formatting of particular calls 
or data structures. 
While in accordance with the provisions and statutes there has been 
illustrated and described the best form of the invention, certain changes 
may be made without departing from the spirit of the invention as set 
forth in the appended claims and that in some cases, certain features of 
the invention may be used to advantage without a corresponding use of 
other features. 
##SPC1##