JPH09265409A - Dynamic execution unit management for high performance user level network protocol server system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To dynamically manage the pool of execution units inside a server system by periodically examining the number of non-used execution units inside a communication pool. SOLUTION: A client object 507 uses an IPC object 511 and performs connection to a server. To a protocol stack 513 for establishing a communication route to a network 505, a thread counter object is added so as to judge whether or not the communication thread of an allowable amount in the server to which a client machine or a client task is requested is exceeded. In the case of exceeding it, the communication route is not prepared and a service to a client process is denied. When the communication route to the server is established, a client port is allocated in the case that usable sufficient threads are present in a thread pool 522 on a server side from a client pool object 521 to a client request.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention relates generally to communications over computer networks, as well as computer protocols that facilitate such communications. More specifically, the present invention relates to object oriented communication interfaces for network protocol access.

[0002]

BACKGROUND OF THE INVENTION The very earliest computer systems were stand-alone processors in which peripherals such as displays and printers and input devices were connected.
Each computer system was independent, with little communication between the computer systems.
Computer networks, such as local area networks and wide area networks, nowadays interconnect multiple computer systems and share a variety of data, services, and resources obtained from the various computer systems coupled to the network. It is well known to achieve profits.

Many communication protocols have been developed for communicating between various computer systems over a network. Examples of well-known network protocols are System Network Architecture (SNA), Transmission Control Protocol / Internet Protocol (TCP / I).
P), network basic input / output system (NetBIO
S), Internet packet switching / sequential packet switching (IPX / SPX), etc. Other communication protocols are also known and widely used, including ISO, IEEE,
It is described in various standards of other organizations. To facilitate the understanding of computer networks, the network functions and associated software are often described as a series of layers. Data transfer between one copy of an application distributed by a network and another copy of the distributed application is accomplished by using an underlying set of communication layer services. In general, each layer in a computer system has a corresponding layer in the receiving computer system such that each layer interacts with its peer layer.

A seven-layer open system interconnection (OS
I) The model is one of the most well known of the description of network communication, but in many communication implementations one or more OSI layers are combined or omitted. The physical layer of OSI is the lowest layer that interacts directly with the network. This involves actually transmitting the bit stream to the network over the physical connection. The second layer is a data link layer in which a physical layer stream is multiplexed and framed into a message. It also provides error detection, synchronization information, physical channel management. The third layer is the network layer, which controls the routing of information by the network. Addressing, network initialization, switching, segmentation,
Services such as formatting are provided in this layer.
The acknowledgment of data delivery may occur at this layer or at the data link layer.

The fourth layer is the transmission, multiplexing, and transmission of transparent data.
It is a transport layer that controls mapping. In contrast to the best effort undertaken below this layer, reliable delivery occurs at this layer if the application requires it. Services such as retransmitting missing data, rearranging data delivered out of order, and correcting transmission errors
Usually done in this layer. The fifth layer is the session layer, which uses information from the transport layer to group individual data as a common activity between two nodes in the network called a session. The sixth layer is
It is a presentation layer including an interface between a session layer and an application layer which is a seventh layer. The presentation layer provides information for use by the application layer without compromising the integrity of the session layer. The presentation layer also interprets data and translates formats and codes, while the application layer provides user application interfaces and management functions.

Another well-known network standard is the IE
It is an EE standard. The main difference between the IEEE model and OSI is that the data link layer, which is the second layer of OSI, is a medium access control (MAC) sublayer and a logical link control (LCC).
It is to be divided into two sublayers called sublayers. The medium access control manages the medium access connection to the communication medium in the control access. Logical link control provides a state machine to support the protocol specified by the associated data link control.

Another well-known technique is object-oriented programming, which encapsulates data and methods in a programming entity called an object. By protecting a given method and data with a public interface, an object oriented program can provide the required functionality with minimal reprogramming while isolating each component from changes to other components. For detailed background information on object-oriented techniques, concepts, and rules, see Object Orie by Grady Booch.
nted Design WithApplications (The Benjamin / Cummins
Publishing Company, 1990) and B. Meyer
Object Oriented Software Construction (Pr
See references such as entice Hall, 1988).

[0008] Several attempts have already been made to apply object-oriented technology to the general area of communication protocols in multiprocessor networks. As will be shown below, it is still a fruitful area of the invention.

[0009]

A method, system and product for dynamically managing a pool of execution units in a server system, the pool comprising:
Dedicated to the communication process between the process and the server process. A minimum and maximum number of execution units are established in the communication process pool. The minimum number of execution units is the number needed to support a typical client load. The maximum number of execution units is an upper limit to support peak client loads without overloading the server system. When a service request by a client is received by the server system, several decisions are made. First, assigning an execution unit to the request determines whether the current number of execution units in the communication process pool will exceed the maximum number of execution units. If so, the client request is rejected. Then assign an execution unit to the request and the client making the request
It is determined whether the number of execution units assigned to the task will exceed the number of execution units assigned for the client task. If so, the client request is rejected. If the result of the determination is negative, the client request is permitted, whereby the execution unit in the communication process pool is assigned to the client request.

[0010]

To determine whether it is necessary to increase or decrease the number of unused execution units in a communication pool to improve system performance,
Periodically review the number of unused execution units.

The above objects, features, and advantages will be more readily understood with reference to the accompanying drawings and the following description.

[0012]

DETAILED DESCRIPTION OF THE INVENTION The present invention is capable of operating on various computers or collections of computers under multiple operating systems. This computer can be, for example, a personal computer, a mini computer, a mainframe computer, a computer operating in a distributed network of other computers, and the like. The specific choice of computer is limited only by the requirements of the disk or disk storage device, but any IBM PC series computer should work for the present invention. IBM
For more information on PC series computers from IBM
PC 300/700 Series Hardware Maintenance , Publicatio
n No. S83G-7789-03 and User's Handbook IBM PC Ser
See ies 300 and 700 , Publication No. S83G-9822-00. One of the operating systems on which an IBM personal computer can operate is
OS / 2 Warp 3.0. For more information on IBM's OS / 2 Warp 3.0 operating system, see OS / 2 Warp V3 T
See echnical Library , Publication No. GB0F-7116-00.

An alternative embodiment computer system is
Runs on the AIX (TM) operating system
Of IBM's RISC system / 6000 (TM) series
It can also be a computer. RISC system /
For the various models of the 6000,RISC System / 600
0, 7073 and 7016 POWERstation and POWERserver Hard
ware TechnicalReference (Document number SA23-2644-0
0) and many other IBM documents. AI
For the X operating system,General Co
ncepts and Procedure-AIX for RISC System / 6000
(Document number SC23-2202-02) and other IBM resources
It is stated in the fee.

FIG. 1 is a block diagram of a computer 10 including a system unit 11, a keyboard 12, a mouse 13 and a display 14. The system unit 11 includes a system bus or a plurality of system buses 21 to which various components are coupled,
The bus provides communication between the various components. The microprocessor 22 is connected to the system bus 21,
A read only memory (ROM) 23 and a random access memory (RA) also connected to the system bus 21.
M) 24. IBM PS /
The microprocessors in the 2 series computers are one of Intel's family of microprocessors, including 386 or 486 microprocessors.
One. However, 68000, 68020, 6803
And includes a variety of reduced instruction set computer (RISC) microprocessors such as Motorola's microprocessor family such as the O. Microprocessor and those manufactured by IBM PowerPC chips or Hewlett-Packard, Sun, Motorola, etc. Microprocessors, not limited to, can also be used in a particular computer.

The ROM 23 includes a basic input / output system (BIOS) that controls, among other codes, the interaction and basic hardware operations such as the disk drive and keyboard. The RAM 24 is a main memory into which the operating system and application programs are loaded. The memory management chip 25 is connected to the system bus 21 and has a RAM 24.
And hard disk drive 26 and floppy
Controls direct memory access operations, including passing data to and from disk drive 27. A CD-ROM 32, also coupled to system bus 21, is used to store large amounts of data such as multimedia programs or presentations.

Various input / output control devices, that is, a keyboard control device 28, a mouse control device 29, a video control device 30, and an audio control device 31 are also connected to the system bus 21. As expected, the keyboard controller 28 becomes the hardware interface for the keyboard 12, the mouse controller 29 becomes the hardware interface for the mouse 13, and the video controller 3
0 is a hardware interface for the display 14, and the audio controller 31 is a hardware interface for the speaker 15. I / O controller 40, such as a token ring adapter, enables communication via network 46 to other similarly configured data processing systems.

One of the preferred embodiments of the present invention is a plurality of instruction sets 48-52 residing in the random access memory 24 of one or more computer systems generally configured as described above. is there. The instruction set is hard-coded until the computer system requires it.
Store in another computer memory such as disk drive 26, removable memory such as an optical disk for final use in CD-ROM 32, or a floppy disk for final use in floppy disk drive 27. be able to. Those of ordinary skill in the art, when physically storing this instruction set, the medium on which it is electrically, magnetically, or chemically stored physically changes and computer readable information is stored on the medium. You should understand that rides. Although it is convenient to describe the invention in terms of instructions, symbols, characters, etc., it should be noted that all of these and similar expressions must be associated with the appropriate physical element. further,
The invention is often described in terms of comparisons, validations, or other expressions that may be relevant to human operators. None of the operations described herein require any action by a human operator to form part of the present invention, which is a machine for processing electrical signals to produce other electrical signals. It is an operation.

The network in which this workstation is integrated is a local area network (L
AN) or Wide Area Network (WAN), the latter including teleprocessing connections to networks of other nodes or systems operating according to known computer architectures. At any node, there may be one or more processing systems, and each processing system may be a single-user system or a multi-user system, generally configured as described above. These processing systems act as client or server workstations, depending on whether they request or provide services. In particular embodiments, the invention operates on multiple IBM compatible workstations interconnected by a network that communicates via one or more of a variety of communication protocols. Software applications can be packaged together or sold as separate applications. A brief description of local area networks can be found in Larry E. Larry E. Jordan and Bruce Churchill (B
ruce Churchill) by Communications and Networking Fo
r The IBM PC (Published by Robert J. Brady, A Prentice Hall
Company 1983) and the like.

In the preferred embodiment, the present invention is implemented in the C ++ programming language using object oriented programming techniques. C ++ is a compiled language. The program is written in a human-readable script, which is fed into another program called a compiler, which produces a machine-readable numeric code that can be loaded into a computer and executed directly by the computer. It is a thing. The C ++ language deals with certain characteristics that make it easier for software developers to use programs written by other developers, while reusing the programs to prevent their destruction or improper use. Greatly control the use. C +
+ Since the language is well known, there are many papers and texts that describe this language in detail.

As known to those skilled in the art, object-oriented programming techniques include defining, creating, using, and destroying "objects." These objects are software entities that contain data elements and routines, ie methods that operate on the data elements. The data and associated methods are treated by the software as entities and can be created, used and deleted as such. Data and functions allow an object to model a real-world entity by its attributes, which can be represented by data elements, and its behavior, which can be represented by its methods.

The definition of an object is performed by creating a "class" which functions as a template for instructing the compiler how to construct an actual object, not the object itself. For example, a class can specify the number and type of data variables and steps contained in a function that manipulates data. In practice, an object is created in a program using a special function called a constructor that builds the object using the corresponding class definition and additional information such as arguments supplied during object creation. Object destruction is done by a special function called destructor.

Many benefits arise from the three basic properties of object-oriented programming techniques: encapsulation, polymorphism, and inheritance. The object is
It can be designed to hide, or encapsulate, all or part of internal data structures and functions. More specifically, when designing a program, the program developer should define all or some of the data variables and all or some of the associated methods as "private", that is, to be used only by that object. You can Other data or methods are "public"
That is, it can be declared that another program can be used. Access to private variables and methods by other programs can be controlled by defining public methods that access the object's private data. This public method forms the interface between private data and external programs.
If you try to write program code that directly accesses a private variable, the compiler will issue an error when compiling the program. This error stops the compilation process and prevents the program from running.

Diversity allows multiple objects and functions that have the same overall format but operate on different data to work independently and produce consistent results. For example, add method to variable A
It can be defined as the plus variable B (A + B).
Even if A and B are numbers, letters, or dollars and cents,
The same format can be used. However, the actual program code that performs this addition is
Depending on the types of variables that make up A and B, they can vary significantly. Therefore, it is possible to create three types of method definitions, one for each variable type (number, letter, dollar). After the method is defined, the program can later refer to that addition method by its common format (A + B), and at compile time the C ++ compiler should check which of the three methods it should use by checking its variable type. judge. The compiler then substitutes the appropriate function code.

A third property of object oriented programming is inheritance, which allows program developers to reuse existing programs. Inheritance allows a software developer to define a class and the objects that are subsequently created from that class so that they are related by a class hierarchy. Specifically, the class is
It can also be called a subclass of another base class. A subclass can "inherit" and access all of its public functions, as if the public functions of its base class were contained in the subclass. Subclasses can also override or modify some or all of the inherited functions by defining new functions of the same format.

By creating new subclasses that borrow the functionality of other classes, software developers can easily customize existing code to meet their particular needs.

By object-oriented programming,
Although other programming concepts are greatly improved, program development still requires significant time and effort, especially if there are no existing software programs available for modification. As a result, a set of predefined interconnected classes may be provided to create a set of objects and additional miscellaneous routines, both of which are for performing tasks commonly found in a particular environment. . Such pre-defined classes and libraries, commonly referred to as "frameworks", essentially provide a pre-built structure for work applications.

For example, a framework for a user interface provides a set of predefined graphic interface objects that create windows, scrollbars, menus, etc. and provides support for these graphic interface objects. May provide "default" behavior. Many frameworks are based on object-oriented techniques, so you can use a predefined class as a base class, with developer-defined subclasses inheriting the built-in default behavior and allowing developers to extend and identify their framework. Can be modified or overridden to create a customized solution for your area of expertise. This object-oriented approach is significantly superior to conventional programming because the programmer does not modify the original program, but rather extends the functionality of the original program. In addition, the framework provides systematic guidance and modeling, while at the same time allowing developers to freely supply specific actions specific to the problem domain.

The invention described below provides a networking framework for providing network services for applications of various computer systems within a computer network.

Protocol Interface Model This section describes the object-oriented protocol interface model and mechanism. Due to the general characteristics of this interface, OSI network
Allows development of all layers of the model. Therefore,
All network layers have a similar syntax, the meaning of which is defined by the specific layer specifications. That is, OS
The objects that implement the various layers in the I-network model are syntactically similar, but their implementation may differ depending on the responsibilities of a particular layer.
Moreover, the objects that implement each layer for a particular protocol, such as TCP / IP, may differ in functionality and implementation from similar layers in another protocol, such as NetBIOS. This is because the two protocols have different responsibilities for each layer. This model also provides a mechanism for defining communication endpoints, reusing endpoints, and monitoring network events. Because it is an object-oriented model, it inherits all the characteristics of an object-oriented implementation, such as code reusability, maintainability, and the ability to update an implementation without affecting client applications.

1. Creating communication endpoints: Creating communication endpoints
Made easier by network definition objects. Each network definition object contains a definition of a client interface. It is an abstraction of the various types of objects that a client program may need to access. Communication end point is TAccessDefinition derived from network definition class
Object.

FIG. 2 shows a class hierarchy of network definition objects. TNetworkDefinition class 1
00 is the method Inst for instantiating the endpoint
It contains antiateDefinition and method DeinstantiationDefinition for destroying communication endpoints. There are also methods to construct a new instance of TNetworkDefinition or to destroy a particular class object, but these methods are common to all classes and will not be repeated in the following discussion.

TAccessDefinition object 101
Contains protocol interface objects that define a particular protocol type and its layers. The TAccessDefinition object 101 functions as a handle of the communication endpoint. In addition, TAccessDefinit
ion object 101 is its parent TNetworkDefin
In addition to the methods inherited from ition, the method AddToTop to add an interface layer to the access definition above what is already added, and the method AddToTop to add an interface layer to AccessDefinition to the one already added at the bottom Method AddToBottom and method GetT to get the highest protocol layer interface
It also includes opOfStack. TEventDefinition class 10
3 is used to monitor network events. TE
For ventDefinition class 103, the following Networ
More on this in the kEvent section.

2. Network Address Class TNetworkAddress class 111 is the base class used to define all protocol address classes and hardware address classes. FIG.
3 illustrates a class hierarchy of protocol address classes. TNetworkAddress class 111 has a method IsOfAddressType for testing the type of address and a method for testing whether it is a group address.
IsGroup, a method IsBroadCast for testing if it is a broadcast address, a method IsMulticast for testing if it is a multicast address, and a method IsNu for testing if it is a null address.
llAddress and. This class has a method GetWireLength to get the wire length of the address,
Method for formatting the address in the header
It also contains AddressToWire and the method WireToAddress to get the address from the header. Operators for determining if a stream arrives at an endpoint or if a stream originates at an endpoint are also part of this class. The method GetClassIdentifier to get a pointer specific to each class is provided by this class.

Instances of the TProtocolAddress class object act as communication endpoints so that protocol addresses can be passed. TProtocolAddre
The ss object 113 adds a method BroadCastAddress for acquiring a broadcast address and a method NullAddress for acquiring a null address. THardware
Instances of the Address object 115 pass hardware addresses to applications as needed. Similarly, the THardwareAddress object 115 has a method Broa for obtaining broadcast addresses.
Add dCastAddress and the method NullAddress to get a null address. Also add a method IsFunctional to test if it is a functional address. TIEEE8023Address class is IEEE802.3
The hardware class address is changed according to the addressing rule. In addition, this is a method to test for a group address.
Add IsGroup, a method SetGroup for setting the group address, and a method ClearGroup for resetting the group address. Other methods are BroadCastAddress to get a broadcast address and IsMulticas to test for a multicast address.
t, NullAddress that gets a null address, and CanonicalAddress that gets an address from standard input.

TTCPAddr 117 and TNBAddr 119 are examples of concrete address classes that represent TCP / IP and NetBIOS addressing details, respectively. Similarly, TIEEE8023Addr121 and TIEEE8025Addr123 are I
FIG. 6 represents a concrete hardware address for addressing IEEE 802.3 and IEEE 802.5.

3. Protocol Interface Class The present invention supports both connection-oriented and connectionless transactions. The invention also describes a state machine that is followed by a protocol independent application. The object hierarchy of the protocol interface class is shown in FIG. The protocol interface class is derived from the base class MProtocolServe 133 which contains the methods for all common functions that the protocol must have. The TProtocolInterface class 135 contains additional methods for network functions. These methods are detailed in Tables 1 and 2 below. Network protocols such as TCP / IP
Derive its TCPIPInterface class from TProtocolInterface to override the default implementation and add its own specific features such as checking for valid flags on send or receive requests. As a separate class derived from the TProtocolInterface class, TSessionInterface13 for the session layer
7. TTransportInterface13 for transport layer
8. TNetworkInterface 141 for network layer, TFamilyInterface 143 for family layer, and TDLCInterface 145 for data link layer are prepared. The object hierarchy is as shown. In this example, O
The SI network layer is divided into a network layer and lower layers called protocol family layers. The family layer contains non-duplicated portions of the OSI network layer, such as routing information. The network layer contains information related to particular endpoints, such as peer addresses and local SAPs. This is done to keep only one object, such as the FamilyLayer object, resident in the system and to keep all global information associated with the protocol. When the client application creates and destroys each endpoint, other protocol layer objects such as the session layer, transport layer objects, and network layer objects are created and destroyed, but family layer and data link layer objects. Will remain resident.

Concrete classes derive from individual interface classes. For example, as explained below,
Concrete classes are provided for transport, network, family interface classes for specific protocols such as TCP / IP to build the protocol stack.

Table 1 As mentioned above, the MProtocolService object functions as a base class for protocol layer definition. MProtoco
The list of methods provided in lService object is shown below. Most of these methods are pure virtual functions.

Bind-Initialize and bind local address Unbind-Unbind local address SendRelease-Start normal release ReceiveRelease-Receive acknowledgment of normal release start GetLocalAddress-Get local address SetLocalAddress-Local address GetPeerAddress-Get peer address SetPeerAddress-Set peer address GetProtocolInfo-Get protocol information SetProtocolInfo-Set protocol information GetProtocolOptions-Set protocol options GetRequestMode-Get request mode SetRequestMode-Request mode GetRetry-Get protocol layer retry parameters SetRetry-Set protocol layer retry parameters GetTimeout-Get protocol layer timeout parameters SetTimeout-Set Set protocol layer timeout parameters GetStatistics-Get protocol layer statistics SetStatistics-Set protocol layer statistics IsSession-Return true if protocol layer is session layer IsTransport-Protocol layer is transport layer IsNetwork-returns true if the protocol layer is the network layer IsFamily-returns true if the protocol layer is the family layer <<<-for receiving the object in the data stream Operator Operator >> =-Operator to send the object to the data stream

Table 2 A list of functions provided in the TProtocolInterface class is shown below.

GetLayerIndex-Get protocol layer index CancelRequests-Cancel all current outstanding requests ReceiveEvent-Received events on this stack GetConnectionInfo-Get connection info and memory constraints BorrowMemory-System for network data ReturnMemory-Return system memory for network data GetAccessDefinition-Get pointer to TAccessDefinition GetLocalAddress-Get local address of layer SetLocalAddress-Set local address of layer GetPeerAddress-Layer GetPeerAddress-Get the layer's peer address GetProtocolInfo-Get the layer protocol information SetProtocolInfo-Get the layer protocol information GetProtocolOptions-Get the layer protocol options olOptions-Set layer protocol options GetRequestMode-Get layer request mode SetRequestMode-Set layer request mode GetRetry-Get protocol layer retry parameters SetRetry-Set protocol layer retry parameters GetStatistics- Get Protocol-Get protocol layer statistics GetTimeout-Get protocol layer timeout parameters SetTimeout-Set protocol layer timeout parameters Bind-Bind protocol stack Unbind-Unbind protocol stack Receive-Get network data Receive-Send network data Connect-Initiate attempt to establish connection ReceiveConnection-Wait for attempt to establish connection Disconnect-End connection ReceiveDisconnect-Wait for disconnect A cceptConnection-Accept an attempt to establish a connection RejectConnection-Reject an attempt to establish a connection Listen-Listen to an attempt to establish a connection ListenForConnection-Listen to an attempt to establish a connection SendRelease-Start normal release => There is no more data to send ReceiveRelease − Acknowledgment to start normal release Receive operator << = − Operator to stream object into data stream operator >> = − Object to data stream Operator to stream out

4. Protocol Layer Implementation Class As mentioned above, the protocol interface model is a collection of objects for accessing the protocol layer.
Functions as a base API. To implement an implementation of a protocol stack such as TCP / IP as a layered set of linked objects, use the TProtocolLayer class. FIG. 5 shows a class hierarchy of protocol layer classes. TProtocolLay
The er class 151 serves as the base class for all layers of a protocol implementation.

The TProtocolLayer class 151 includes methods for functions such as Transmit, Connect, Receive, and Disconnect that are implemented in each layer. These methods are detailed in Table 3 below.

Concrete classes for protocols such as TCP / IP derive from these layer objects and incorporate their specific protocol layer meanings.

Each child object 153-161
Inherits these methods and overrides them if they apply to a particular protocol layer.

Table 3 The main functions of the TProtocolLayer class are shown below.

Dispatch-dispatch inbound packet to upper layer Transmit-transmit outbound packet to lower layer DispatchEvent-dispatch event to upper layer TransmitEvent-transmit event to lower layer ReceiveEvent-report event Enable CancelReceiveEvent-Cancel event reporting InstantiateInterface-Create interface object from layer object GetUpperProtocol-Get pointer to next higher layer GetLowerProtocol-Get pointer to next lower layer Bind-Protocol- Unbind to bind stack Unbind to unbind protocol stack Connect-Initiate attempt to establish connection ReceiveConnection-Wait for attempt to establish connection Disconnect-End connection GetPacketQueue-Inbound data Packet returns a pointer to the packet queue in which the packet is available ReceiveDisconnect-waiting for disconnect AcceptConnection-accepting connection initiation RejectConnection-rejecting attempt to establish connection Listen-listening connection attempting to listen ListenForConnection-listening connection Listen for attempts to establish SendRelease-Start normal release => no more data to send ReceiveRelease-Acknowledge start normal release operator Operator << =-Operation to marshal TProtocolLayer object to data stream Child operator >> = − Operator to unmarshal the TProtocolLayer object to the data stream

5. Protocol State Machine This section describes the states of protocol interface objects that are possible for both connection-oriented and connectionless operations. The protocol state machine is shown in FIGS. These state machines show typical state transitions in the protocol, but different choices are possible depending on the implementation of the protocol. However, this state machine ensures application portability and allows protocol independence. Applications that require protocol independence should use the state machine described below, and the state machine should be implemented by a protocol that supports protocol independence.

The protocol endpoint for a particular protocol interface layer object should be in one of the states described below. These states are typically application states. Layer objects follow a state machine defined by a particular protocol. Normal,
These states are meant to show the valid calls that the user can make in various "endpoint" states and how to create the application. The layer state is controlled by the meaning and state of the layer.

The uninitialized state 201 defines the starting state of the endpoint which is also the final state of the endpoint. This is the state before the access definition is created.

Once the TAccessDefinition object is created (202), the endpoint is said to have been initialized. In the initialized state 203, the Set operation could be used to build and initialize the interface object. Set operations are cached locally on the interface object, so there is little room for validation of the settings. That is, InstantiateDefinit
The send / receive capacity can be set on the interface object before the protocol layer object is created by the ion method. It is not possible to validate such values on the interface, since only the layer object knows information about such capacity limits. The layer object does not exist until the InstantiateDefinition method is called on the AccessDefinition object. When a request is made to destroy the TAccessDefinition object 204, the endpoint moves from the initialized state 203 to the uninitialized state 201.

When the instantiation request 206 is made on the TAccessDefinition object, the end points are in the unconnected state 20.
Move to 7. The unbound state 207 defines a state that occurs immediately after the layer object is instantiated.
You can issue Get / Set operations to modify the values.
Such requests are no longer cached in the interface object, but are sent to the corresponding layer object for processing and storage. When the instance cancellation request 208 is made on the TAccessDefinition object, the endpoint moves to the initialized state 203.

To bind a local address
When the Bind operation 210 is issued, the endpoint is in the unbound state 207.
To the combined state 209. The endpoints of the data transfer in the connectionless mode can start sending and receiving data when in the "bonded" state. When the unbind request 212 is issued to the stack in the combined state 209, the end point returns to the uncombined state 207.

When the Listen request 214 is issued, the endpoint moves from the combined state 209 to the listening state 213. The protocol stack will accept incoming connection requests for that local name until the user-specified queue size is exhausted. Incoming connection 216 allows a new activity protocol
A stack is created.

When the Connect request 220 is issued at the active endpoint, the endpoint transitions from the combined state 209 to the connected (client) state 219. As shown in FIG. 7, endpoints using the service in connectionless mode enter the "data transfer" state 225 after a successful connection request. For passive endpoints, when an incoming connection request is received, the protocol stack creates a copy of the layer and interface objects and a new TAccessDefinition for the received connection request. The newly created endpoint is then connected (server)
State 221 is entered. The arrow is on the dotted line from the listening state to the connected (server) state. The application can choose to accept or reject the connection. In AcceptConnection, the endpoint should be in data transfer state 225. If the connection request 226 is rejected, the endpoint transitions to the inactive state 229.

The newly created stack has a connection request 222.
After completing, the endpoint enters the data transfer state 225. After receiving the Disconnect request 228 from the local application or the connection being terminated by the connection partner, the connection endpoint moves to the combined state 209. However, in such cases, the application will receive ReceiveDisco.
Note that you can issue the nnect request to receive the end data.

If the incoming connection request is rejected by the application, the endpoint transitions to the inactive state 229. The endpoint is then destroyed by issuing a TAccessDefinition destroy operation 230.

6. Example Here is an example of how to use the object oriented model of the present invention for a network protocol such as TCP / IP. The TCP / IP implementation includes a transport layer, a network layer, and a TCP / IP family layer. In addition, the networking subsystem includes a TDatalink layer object that resides within the system, and the TCP / IP FamilyLayer object provides the means to access the TDatalink layer. However, in this embodiment, the TDataLink layer object is T
Common to all network protocol stacks such as CP / IP, SNA, NetBIOS, TDatalin
Note that the k-tier object derives from the TProtocolLayer class object.

The TCP / IP interface (API) class is derived from the TProtocolInterface class.
FIG. 8 shows the class hierarchy of some objects in the TCP / IP implementation. As mentioned above, TProtocolInterface and TProtocolLayer are child classes of the MProtocolService class that provide API and protocol implementation functionality. TTCPTINF
251, TTCPNINF 253, and TTCPFINF 255 objects (collectively referred to as TTCPXINF) are TCP / IP.
TTransportInterface class for the protocol, TNetworkI
TProto representing nterface class and TFamilyInterface class
It is an example of a concrete class of colInterface. However, TCP
Note that there is no instance of the TSessionLayer class as there is no concept of "session" in the / IP protocol. Similarly, TTCPTIMP257 and TTCPNIMP
259 and each object of TTCPFIMP261 (collectively
Called TTCPXIMP) is TTRA for the TCP / IP protocol.
nsportInterface class, TNetworkInterface class, TF
It is an instance of the amilyInterface class.

As described above, the TDatalinkLayer 161 is
The implementation object for all network protocols in this example, TProtoco
It is a subclass of the lLayer class 151.

Further, the TTCPProtocolAddress class is prepared for the application so that the IP address can be passed. The TTCPProtocolAddress will contain a 4-byte IP address and a 2-byte port address.

The process required by the application to access the TCP / IP protocol is described below with reference to FIG. In most cases
The "application" is most likely to be the communication API layer, such as the BSD socket interface, where the user level application makes API calls. The socket interface should eliminate the need for application developers to understand the specific syntax of network protocol objects. But,
An "application" can also be an operating system service familiar with the name of the object model of the present invention. In the following example, the application accesses the transport layer. Applications can access any layer. It is also possible to talk directly to the network layer. Currently, it is common for there to be no user application. These steps are very similar at high level to those of the procedural implementation of the TCP / IP protocol. However, it has been implemented in an object-oriented manner using the protocol interface model of the present invention.

In step 301, a communication endpoint is created to access the TCP / IP protocol. This is done by first creating a TAccessDefinition object. For example, C ++ is used to build a "new TAccessDefinition". Then TAccess
The TTCPxINF interface object is created and added to the AccessDefinition using the methods in the Definition. The InstantiateProtocol method is then called on the TAccessDefinition object, which in turn creates the TTCPxIMP layer object.

In step 303, the address is combined with the communication end point created in step 301. This is done by creating a TTCPProtocolAddress object with the required IP address from the prepared TTCPProtocolAddress class object. The TTCPTINF-> Bind () method is then called to bind that address. This step involves TTCP on the protocol implementation layer, including the meaning of binding.
This will invoke the IMP-> Bind () method.

Next, in step 305, the application connects to the listening peer function by invoking the TTCPTINF-> Connect () method (in the TTCPTINF object) to initiate a connection request. This allows (TTCPTIMP
(On the object) the TTCPTIMP-> Connect () method is invoked, which then calls the lower layer, namely TTCPNI
Perform the necessary steps to set up a TCP / IP connection by calling the TTCPNIMP and TTCPFIMP objects for the MP-> Connect () method and the TTCPFIMP-> Connect method, respectively.

After successful connection, in step 307, data can be sent and received by the resulting protocol stack. Applications call the TTCPTINF-> Send () and TTCPTINF-> Receive () methods to send and receive network data. TTCPTINF-> Send () then calls the TTCPTIMP-> Xmit () method to start data transmission of the TCP protocol. The data is passed from the protocol layer object to the protocol layer object using the Xmit () function of each protocol layer and delivered by the communication adapter to the TDataLinkLayer object. Similarly, for the receive function, TDataLinkLayer receives data from the physical layer and passes it to the appropriate protocol family layer, which in turn passes it to the appropriate stack. But,
In one embodiment, the data is queued until a request to receive data from the client is made and the data is copied from the data queue to the client.

In step 309, the connection is closed after the desired communication is completed. Application is TTCPTINF->
Call the Disconnect () method to start the connection termination. This then calls TTCPTIMP-> Disconnect (), which handles the TCP / IP disconnect state machine for TTCPTIMP which may send the method down to the family layer for certain implementations.

Finally, in step 311, TAccessDef
The endpoint is closed by deleting the inition object.

Referring to FIG. 10, it may be helpful to understand the relationship between various objects and the network layer. On the left side of the figure, the TCP / IP embodiment described above in connection with FIGS. 8 and 9 is shown. The TCP / IP applications 313 and 315 communicate with the object-oriented protocol stacks of the following layers via the socket API 317, both of which are in the application layer. The TProtocolAddress object used by the socket API to create the communication endpoint is not shown. Each TCP / IP application 313, 315
Each communication end point, that is, each TProtocolAdd
ress object is required.

As described above, since there is no concept of session layer in TCP / IP, the socket API 317 communicates with the TTCPTINF object 251 in the transport layer. As described above, the TAccessDefinition object 318 includes the TTCPxINF objects 251, 25 of the transport layer, the network layer, and the family layer.
3, 255 are included. Although it is relatively rare for user-level processes to contact the protocol stack over a family layer network, the TTCPNINF object 253 and TTCPFINF are primarily used by operating system services to reach these layers. An object 255 is provided.

The TTCPTINF object 251 is the TTCPTINF
-> TTCPTIMP object 25 by Connect () method
Connect to 7. This allows the TTCPNIMP object 25
TTCPTIMP-> Connect () method to connect to 9,
TTCPNIMP to connect to TTCPFIMP object 261
-> Connect () method is started. Also, TDataLinkL
TTCPFIMP-> Connect to connect to ayer object 161
() Method is started. As shown in the figure, TTCPTIMP2
57, TTCPNIMP259, TTCPFIMP261, TDatalinkLay
The objects of the er 161 are in the transport layer, the network layer, the family layer, and the data link layer, respectively. As described above, the send / receive method allows network data to be sent on the protocol stack via the physical adapter 319 in the physical layer.

In the preferred embodiment, a TDataLinkLayer object 161 is created when a communication endpoint is created and deleted.
And the TTCPFIMP object 261 is immutable and stand alone. The remaining objects (251, 253, 255, 257, 259, 318) for each activity endpoint
Each requires a separate thread and instance of. As one of ordinary skill in the art will readily appreciate, the overhead associated with such an arrangement can cause performance problems in the case of a network protocol server with potentially thousands of client connections. is there. As described in the Dynamic Execution Unit Management section below, the present invention provides a means for dynamically managing execution threads for maximum performance.

On the right side of the figure, an implementation of NetBIOS is shown. Accordingly, the present invention contemplates a multi-protocol environment in which the system supports multiple applications running multiple network protocols. As shown in FIG. 10, NetBIOS applications 331, 333.
Is a socket API 317 or special NetBIOS
It can interact with lower layers via any of the API layers 335. Thus, the present invention also contemplates multiple applications accessible to the object oriented protocol stack of the present invention. Such applications can be object-based or procedure-based user-level applications or operating system-level processes.

As mentioned above, a similar process is used to establish the NetBIOS stack. However, Net
Since BIOS does not mean the session layer, AP
Note that the I-layer 317, 335 connects to the session-layer TNSINF object 337. NetBIO
TNSINF337 which is an S interface object,
TNTINF339, TNNINF341, TNFINF343 and Net
TNSIMP34, which is a BIOS protocol layer object
7. After TTNIMP349, TNNIMP351, and TNFIMP353 are created, TNSINF object 337 causes TDataLinkLayer object 1 through the protocol layer object.
A communication path is established up to 61. As in the TCP / IP embodiment, the TDataLinkLayer object 161 and the TNFIMP object 353 are immutable and stand-alone, with each active communication endpoint creating and deleting a separate instance of each of the remaining objects.

The present invention can deal with a plurality of adapters 319, 321 coupled to the TDataLinkLayer 161. The upper layers provide proper routing to the communication endpoints so that these adapters can be used simultaneously for different network protocols. Further, these adapters can be of different types, such as Ethernet and Token Ring, so that the server can serve the demands of different networks.

7. Protocol Utility Class This class is a TProtocolInterface class and a TProtocolL
It is used by the ayer class. Most of this class serves as a parameter to various methods in the interface and implementation classes. This class emphasizes the general features of the proposed model.

This section describes some of the important classes used by the protocol interfaces.

A. TProtocolInfo Class This class identifies various characteristics of the protocol such as service type, maximum message size, preferred data length, and so on. Following are some of the important methods provided by this class.

These are used to specify the characteristics of the end points when creating the end points.

GetPSDUSize-Get maximum size of protocol service data unit SetPSDUSize-Set maximum size of protocol service data unit GetEPSDUSize-Get maximum size of preferred protocol service data unit PSDUSize-Set the maximum size of priority protocol service data unit GetConnectionDataSize-Get the maximum size of connection data SetConnectDataSize-Set the maximum size of connection data GetDisconnectDataSize-Get the maximum size of disconnect data SetDisconnectDataSize -GetDisconnectDataSize to set the maximum size of disconnection data-GetDisconnectDataSize to acquire the maximum size of disconnection data-SetServiceconnectDataSize to set the maximum size of disconnection data-SetServiceType to acquire the service type such as connection / disconnection To set the service type SetServiceType - to set the service type SetServiceFlags - to set the service flag

B. TProtocolOptions Class This class is used to define protocol-specific options, including quality of service. However, this base class does not include a particular quality of service. It is assumed that the concrete class derives from TProtocolOptions and contains its own options.

GetLingerTime-Get protocol linger time SetLingerTime-Set protocol linger time GetSendbufSize-Get protocol send buffer size SetSendbufSize-Set protocol send buffer size GetRcvbufSize-Get protocol receive buffer size SetRcvbufSize-Set protocol receive buffer size

C. TSendModifiers class The TSendModifiers class modifies the flags related to the network transmission function in the TProtocolInterface :: Send method and TProtocolLayer :: Xmit () method. In addition to support for send timeouts, the instructions that can affect the send function are:

KPush-request immediate processing kEdnOfMessage-mark end of message kExpeditedData-treat data as preferred data kNotify-notify sender when client buffer is available kSendAll-all "n" bytes Block until buffered kNoFragmentation-Do not fragment data

The following are some of the important functions supported by this class:

GetSendModifier-Get value for SendModifier SetSendModifier-Set SendModifier to ON ClearSendModifier-Set SendModifier to OFF GetTimeout-Get send timeout SetTimeout-Set send timeout

D. TReceiveModifiers Class This class is used to define the receive flags in the TProtocolInterface :: Receive () function.

This class contains methods and definitions for setting flags and timeouts while receiving network data. It is as follows.

KPeek-Peak user data kExpeditedData-Receive priority data kReceiveAll-Block until'n 'bytes have been received kBroadcastData-Receive broadcast datagram kDiscardBufferOverflow-Message overflowing receive buffer Discard part of kDatagramAny-receive either a regular datagram or a broadcast datagram

Some of the important functions in this class are:

GetReceiveModifier-Get value for ReceiveModifier SetReceiveModifier-Set ReceiveModifier to ON ClearReceiveModifier-Set ReceiveModifier to OFF GetTimeout-Get receive timeout SetTimeout-Set receive timeout

E. SendCompletion class SendCompleti in response to a network data send operation
The on object is returned. It shows the status of the send function and also shows the total number of bytes sent. The situation instructions are as follows:

KNormal-Normal completion kTimeout-Send timeout kCancelled-Application canceled send request

Some of the important methods of this class are:

GetSTatus-Get the SendCompletion status SetStatus-Set the SendCompletion status GetBytesTransferred-Get the number of bytes of client data to send SetBytesTransferred-Set the number of bytes of client data to send

F. TReceiveCompletion class ReceiveCompl in response to network data reception request
An etion object is returned. This indicates the status of the receive function and the total number of data received bytes. The situation instructions are as follows:

KNormal-Normal completion kPushed-Sender "pushed" data kNoMoreData-Stream ended or receive pipe closed kEndOfMessage-End of message detected kExpeditedData-Priority data received kTimeout-Reception Timeout kMessageTruncated-partial message, rest discarded kCancelled-cancel request processed kMore-ready to receive additional data

Some of the important functions in this class are:

GetStatus-ReceiveCompletion Get status SetStatus-ReceiveCompletion Set status GetBytesTransferred-Get number of bytes of client data to receive SetBytesTransferred-Set number of bytes of client data to receive

Network Event Management This section discloses an object-oriented solution to the problem of accessing network events on multiple network protocol stacks and storing them at various protocol layers. The present invention provides a single and consistent set of class definitions for all network events based on the OSI network protocol layer model. Since events are defined for each generic OSI layer, each implementation of these layers should be able to choose to add additional layer-specific events by defining additional subclasses. This solution is
Being an object-oriented model, OO technology makes full use of diversity and inheritance.

The classification of events based on the OSI layer clearly categorizes events stored and reported at the protocol layer. This categorization allows events to be retrieved for a particular layer if they are important to the application. Such an event may describe conditions for an established client communication session, such as data being received and available for reception, the connection being dropped, etc. Clients can use a single call to monitor for these asynchronous events on any protocol layer of multiple protocol stacks. The present invention eliminates the need for applications to look for individual endpoint events, TCP / IP and NetBI.
It covers event reporting by multiple protocols such as OS. In addition, the network event mechanism allows network objects to send and receive network events between layer objects.
It facilitates communication between protocol layers.

1. Event description Events are defined using a base class called TProtocolEvent. FIG. 11 shows the class hierarchy among various event objects. Figure 11 is similar to Figure 2, but with TEve
TProtoco, which is a subclass of ntDefinition class 103
The lEvent class 401 is also shown. TProtocolEvent class 401 is the event of the listed classes and all OS
It contains a set of events commonly used at layer I and a reserved range of values for individual protocol layer events. The TProtocolEvent class has methods for setting and getting event and membership questions. The network events in one embodiment are set up as bit vectors. In this class, the GetCnt method returns the number of events currently in this object. This is a typical way to specify a list of optional events in this case, another commonly used method is to use a bit mask. Due to the power of object-oriented technology to hide all data within an object, only a single object is needed, and that object provides the methods to get them.

Depending on the particular network protocol, protocol events can be defined by redefining event values in the TProtocolEvent class. TPro
Some of the important methods of tocolEvent are GetEvent, which returns the event at the identified index, HasA which searches for a specific event (membership) in the list, GetCnt which returns the number of events in the object, and endpoints. GetAccessDefinition that returns the access definition shown, SetAccessDefinition that sets the access definition for the endpoint, and SetEvent that sets a single event in the TProtocolEvent object.

2. Event Interface to OSI Layer Implementation As described in the Protocol Interface Model section above, in the preferred embodiment, the network protocol layers are implemented as a series of TProtocolLayer objects, each representing a particular OSI layer. There is. These objects are chained together to complete the protocol stack. For example, the TCP / IP stack can include objects for the transport layer, network layer, data link layer. Each protocol layer object has two event interfaces, namely ReceiveE defined in the TProtocolLayer object.
It has a vent interface and a CancelEvent interface. In these layers, the DispatchEvent method is used to pass the event to the upper layer object, and the TransmitEvent method is used to send the event to the lower protocol layer. Storing events in the appropriate layers is the responsibility of the protocol stack implementation.

The event related method of the TProtocolLayer class dispatches an event to the upper layer DispatchEvent
And TransmitEven that transmits the event request queue to the lower layer
Rece reporting event (s) by adding tProtocolEvent object to t and EventRequestQueue
CancelRecei that ignores iveEvent and EventRequestQueue
veEvent.

3. Event monitoring by application TProtocolI that provides a base class for object-based APIs for each network protocol layer
The nterface class object contains functions that endpoints can use to receive network events. TP
The event-related function of the rotocolInterface class is a ReceiveEvent method that receives the event (s) set in the TProtocolEvent object for a specific communication endpoint.

When an application needs to monitor events at multiple communication endpoints, it uses the TEventDefinition object. The TEventDefinition object is
Acts as an object endpoint for monitoring events. Instances of this object are created and deleted as required by the application. TEventDefini
The main method of action object is TEventDefinition
Inst that instantiates an instance of the object
deInstantiateDefinition that destroys the antiateDefinition and instance of the TEventDefinition object
And a ReceiveEvent that receives events from multiple stacks in an array or queue of TProtocolEvent objects.
Any and CancelRequest that cancels the pending event request.

A. Receiving an event at one communication end point The application is TProto for a specific network layer.
You can use the ReceiveEvent method on an instance of the colInterface class to receive an event at a particular endpoint. However, the endpoint is the TProtocolInt for that protocol.
Note that the erface object is used to access the protocol. The application program sets the required event in the TProtocolEvent object and then calls the ReceiveEvent method. TProtocolI
The nterface object returns a TProtocolEvent object containing the event, if any.

The process of receiving an event at one communication endpoint is shown in the flow chart of FIG. In this example, the transport layer is the top layer, events are stored in the network layer, and requests from applications are made to the transport layer.

Another alternative is to set up a direct event interface to that layer to receive events. However, this process requires that all layers be treated in that way even for less favorable events. Since it is better to get from one point, the client makes a call to get the event from all layers using the event vector as the selection criterion.

FIG. 12 shows the event receiving mechanism at a single endpoint. Requests to receive one or more events at the endpoint are made to the interface object using the TProtocolInterface :: ReceiveEvent () method 411. The resulting TProtocolE reported from the endpoint
A ProtocolEventQueue 413 including vents is created internally. The request is then sent to the corresponding layer object using the TProtocolLayer :: ReceiveEvent () method 415. The figure shows how requests are sent between layer objects. TProtocolEventQueue is Rec
Sent as a parameter in the eiveEvent request. The protocol layer object is responsible for the TProto
Disable colEventQueue TProtocolLayer :: CancelEve
TProtocolEve to this queue before receiving an nt () request.
Queue nt. TxxTra depending on the event requested
nsportLayer is a TransmitEvent of TProtocolLayer class
The request can be sent to the TxxNetworkLayer using the () method (417). Similarly, if the event request needs to reach lower layers, TxxNetworkLayer may also send the request to TxxFamilyLayer (419).

When the event occurs asynchronously, TProtocolL
The ayer object can report the event to upper layers using DispatchEvent () (421). The network layer then reports this event to the TxxTransportLayer (423). The TxxTransportLayer queues the reported event in the ProtocolEventQueue (415).
The event is then reported to the caller (411).

B. Receiving Events at Multiple Communication Endpoints An application can create endpoints for multiple communication endpoint events by using the TEventDefinition object. As shown in FIG. 11, TEve
The ntDefinition class 103 is derived from the TNetworkDefinition class 100. The TEventDefinition object 103 functions as an endpoint for monitoring an event of an arbitrary number of endpoints by an arbitrary protocol. For each communication endpoint that is of interest to the application program,
The required number of ProtocolEvents are set in the TProtocolEvent object. That is, a pair of 2-tuples (end points, protocol events) is formed for all end points for which the event is monitored. Then the application
Pass in a set of requested events from various endpoints to get TEventDe
Call ReceiveEventAny () method of finition object. ReceiveEventAny is TProtocolEvents
Put an event in the queue and return, or time out. However, all communication end points are TAccessDefinit
Note that it is created using ion class.

FIG. 13 shows the flow of event reception at a plurality of end points.

FIG. 13 shows an event receiving mechanism at a plurality of end points. The application creates a TEventDefinition object that acts as an event endpoint (45
1). Then the application will run one per endpoint,
Create an array of TProtocolEvent objects (45
3). The array of requested events at the endpoint is passed as a parameter to TEventDefinition :: ReceiveEventAny () (455). ReceiveEventAny () method is TProtocol
Create an EventQueue (457) and send a queue to all endpoints where the event is searched (461). Receive request via ReceiveEvent request (463) TxxProtocolLayer
Can send event requests to layers below it. This is the same for any endpoint (46
5). When TxxProtocolLayer receives an event asynchronously, it dispatches the event to the upper layer or TP
Events can be reported in the rotocolEventQueue. When an event enters the TProtocolEventQueue, TxxProtocolLayer :: CancelEven is added to the TxxProtocolLayer of all relevant endpoints.
t () is sent. Next, ReceiveEventAny method 455
Returns all TProtocolEvents from the TProtocolEventQueue
(459) and report it to the caller. The queue should be empty if there are no events to report.

After the response is received from either endpoint,
All endpoints receive a CancelEvent request, ProtocolE
Indicates that the life of the ventQueue object has ended.
If the request is canceled, the event is still stored at the protocol layer. The client can return with another ReceiveEvent the next time it gets a new event. This embodiment uses the pull model from the client, which means that the client gets the event when it is convenient for the client.
The set of ProtocolEvents collected is returned to the caller.

Dynamic Execution Unit Management In multitasking systems, network protocol stacks such as TCP / IP can be efficiently implemented using a client / server model. The server uses a multitasking technique to support a large number of clients at the user level.
Can be a task. It is often necessary to pre-allocate a fixed set of server resources to a particular process in order to guarantee sufficient performance when supporting a large number of clients. One of the important server resources is the number of allocated server execution units. OS
In modern operating systems such as / 2 and Windows NT, the basic unit of execution is a thread. Many current systems are equipped with "lightweight" threads (meaning fast thread switching), but unfortunately thread creation / deletion is proposed by the present invention when scaled to support thousands of clients. Is not "lightweight" enough to support the performance requirements of network protocol servers such as

Furthermore, as the number of threads increases, the performance of the system, ie, the server, drops significantly. Thread switching overhead tends to increase proportionally as the number of threads increases, in addition to the footprint allocated in the system. This is even better for network servers that are likely to need to support multiple simultaneous requests from the same client, such as sending and receiving data in two threads in full duplex under a network session. It gets complicated. As a result, the number of threads in a server dedicated to supporting multiple simultaneous clients can be very large.
Therefore, efficient management of server execution units such as threads is important to the server's ability to support a large number of clients with sufficient performance.

Here, a method for the network protocol server to dynamically manage the number of execution threads is disclosed. This method reduces the thread resources needed to accommodate a large number of clients. Ingress control is provided so that each client does not consume all thread resources allocated to the server. At the same time, it never waits for server thread resources to keep a particular client dead.

[0120] 1. Server Execution Unit Management Server threads are created and managed in the server thread pool. First, when the server starts, a server management thread is created. In the preferred object-oriented embodiment, this is done by instantiating a TNetworkServer class object that contains the methods for managing the client port pool and network server thread pool described below. The server management thread is responsible for managing the server thread pool by coordinating the creation or deletion of server threads in the thread pool. The server management thread is normally dormant. This is triggered periodically by a request signal and a timer.

All client request services must first establish a session with the server.
Session requests are sent to a single server communication endpoint called session_port. After establishing a communication session with the server, each client is assigned a unique communication endpoint called client_port. In the preferred embodiment, TAcces
There is a one-to-one correspondence between the sDefinition object and each client_port assigned on the server side.

The client and server can interact with each other using the RPC mechanism. The remote procedure call (RPC) mechanism provides the required request routing and ingress control as described below. The RPC mechanism can be built on top of internal procedure call (IPC) services of the underlying operating system's internal process communication. In addition to locating server tasks,
The basic RPC primitives are:

Client side ○ SendRequest (server_port (session or client), request_data, reply_data) Server side ○ ReceiveRequest (request_data) ○ SendReply (reply_data)

The client_port for all clients is cli
Collected in the ent_port pool. Its assigned client_port
Using, the client can make a network request to the server. The server manages requests from the client_port pool and assigns threads in the thread pool to service requests received from any number of client_port pools. FIG. 14 shows the control and management flow of the client_port pool and the thread pool in the first embodiment of the object oriented network, but the client and server application objects are multi-processors such as symmetric multi-processor (SMP). It resides in the memory allocated to the various processors of the processor configuration, and both communicate via the object-oriented RPC interface.

The plurality of client machines 500 contact the server machine 503 via the network 505. Each client machine 500 may have a plurality of client application objects 507 resident, each capable of making client requests. As shown, the client
The object 507 sends its request to the appropriate RPC / API object in the RPC / API layer 509, which layer uses the IPC object 511 running in a different address space to connect to the server. The protocol stack establishes a communication path to the network 505. According to this embodiment, a thread count object, detailed below, is used to determine whether a client machine or client task has exceeded its capacity of communication threads at the requested server. It has been added to the stack. If not, then no communication path is created and the client process is instructed to wait for an available thread, or the protocol stack will simply deny service to the client process. Although only one server is shown in the figure, the thread count object can track client accounts on multiple server machines in the network.

Assuming that a communication path to the server is established, the protocol stack 513 assigns a session port which is a communication end point on the server side.
Receive a client request to send to port object 519. The client port is assigned to the client request from the client pool object 521. The client port is the client communication endpoint returned to the client protocol stack when there are enough threads available in the server side thread pool 522. Session port allocation, client port pool, thread
A set of network protocols that manage pools and
The server object is described in detail below. Once threads, client ports, and session ports are allocated, the server set's RPC / API
Object 515 and upward server service 51
Communication to 7 can continue.

Dynamic execution unit management can also be implemented in procedure-based systems. Further, as shown in FIG. 15, in this mechanism, the memory has a client space 53.
1 and a single processor machine divided into a server space 533, a plurality of client tasks 535, 537,
It can also be applied to an environment in which 539 operates on the same machine as the server task 540. The client task sends the request to the server task via the RPC library interface 541 on the client side. The request is first processed on the server side by the RPC library 543 on the server side. The session port process 545 then allocates the session port and allocates the client port from the client port pool 547. Protocol stack 5
Threads are allocated from thread pool 549 so that 51 can handle client requests to network 553.

The number of threads in the pool is controlled by a number of system configuration variables. Modification of these variables can be done by the system administrator using the user configuration program.

O (MinThreads) -This is the minimum number of threads reserved to service client requests. This limit is to maintain the minimum number of threads used to support a typical server-loaded client.

O (MaxThreads) -This is the maximum number of threads reserved to service client requests. This limit is used as an upper limit on thread resources dedicated to serving peak load clients without overloading the server system.

O (MaxReq) -This is the maximum number of concurrent requests allocated to a given client.

O (TotalThreads) -This is the total number of threads created to service all client requests. This value will always be between MinThreads and MaxThreads.

O (ReservedThreads) -This is the total number of threads reserved to support all client sessions.

O (Unusedthreads) -This is the number of unused threads in the pool.

O (Clientthreads) -This is the number of activity requests the server serves for each client.

The number of threads in the pool will increase or decrease dynamically based on the number of active client requests being serviced at the same time.

The process used to manage the number of threads, ie the method of the object oriented embodiment, is described in detail below with reference to FIGS.

Referring to FIG. 16, at server initialization in step 575, <MinThreads> threads are created and inserted into the thread pool. In this step, (UnusedThreads) and (TotalThreads) are (M
inThreads) and (ReservedThreads) is set to 0. In step 577, the new client requests a session with the server. On the server side, after receiving the client request, (ReservedThreads) + (Max
A test is performed at step 579 to determine if Req) <= (MinThreads). If this result is true, then there are enough threads to support existing and new clients and no action is taken to tune the thread pool.

In step 581, the server assigns client_port to the client task and returns. In step 583, (ReservedThreads) is incremented by (MaxReq) and the process returns to step 577 to wait until the new client requests a session.

If the test at step 579 is negative, then a test is made at step 585 to determine if the maximum number of threads is exceeded if the client request is granted. (MinThreads) <(ReservedThreads)
+ (MaxReq) <(MaxThreads) is tested. If the result is true, then the thread limit has not been exceeded and the process moves to step 581 to allocate and return the client port for the client task.
At step 583, (ReservedThreads) becomes (MaxRe
q) is incremented. As we will see later, the process in this figure looks the same for this branch and the one above, but the managing thread has a new count (ReservedThread).
Asynchronously increments the thread in the thread pool the next time it is awakened based on s).

If the test in step 585 is positive, that is, (ReservedThreads) + (MaxReq)> (MaxThre
ad), the client request is rejected in step 587. Therefore, the server manages client session entry control to avoid overload situations. In step 589, the server should enter a wait state and probably notify the client until the thread is released from other client tasks. Alternatively, the server simply rejects the client request and allows the client to try again later.

The following pseudo code shows an implementation of this process.

New client request session with server On the server-If (ReservedThreads) + (MaxReq) <= (MinThreads), (ReservedThreads) increment by (MaxReq) Assign and return a client_port to the client If (MinThreads <(ReservedThreads) + (MaxReq) <(MaxThreads) Increment (ReservedThreads) by (MaxReq) Assign and return a client_port to the client If (ReservedThreads) + (MaxReq)> (MaxThreads) Reject the network request

FIG. 17 shows the client side process for managing the client request ingress control. In step 601, the client task makes a new network request using the client port assigned to the server. In step 603, a test is performed to determine if the client task has available threads out of the allowed number of threads on the server side. To determine this, a test for (ClientThreads) <(MaxReq) can be used. If yes, step 6
At 07, the client request is sent to the server. At step 609, the number of current client threads is incremented.

If all of the allowable number of threads on the server side are in use, then in step 605 the network request is rejected or waited until the number of simultaneous requests from this client is less than (MaxReq). enter.
When in the wait state, if one of the allowed threads is released, the process can proceed from step 605 to step 607.

Also shown in FIG. 17 is a server-side process for allocating server threads in a thread pool and adjusting the number of threads in the pool to service client requests. At step 611, a server thread is assigned to the client request for the duration required to process the client request. Step 613
Now, the (UnusedThreads) variable is decremented. At step 615, a test is performed to determine if the number of threads in the thread pool is acceptable.
((UnusedThreads) <(MinThreads) & (TotalThreads
s) <(MaxThreads)) is one of the tests for performing this step. thread·
If the number of available threads in the pool is unacceptable, the administration thread is notified to increase the number of threads in the thread pool. The process is step 6
It ends at 19.

The following pseudo code shows an implementation of this process.

Client issues network request to the server If (ClientThreads) <(MaxReq), Send the request to the server.Increment (ClientThreads) else Reject the network request

Assign server thread to service client request Decrement (UnusedThreads) If (UnusedThread) <(MinThread) & (TotalThread) <(MaxThread) Increase threads in the thread pool

FIG. 18 illustrates the process followed by the client and server when the server completes the client network request. On the server side, in step 625, the server has completed any processing required for the client request. Step 62
At 7, the response to the client request is sent through the protocol stack. Next, in step 629, the server thread is returned to the thread pool. next,
In step 631, the (UnusedThreads) variable is incremented.

On the client side, in step 635 the protocol stack receives the response from the server. In step 637, the (ClientThreads) variable is decremented to allow other client tasks to use the client allocation of the communication thread. In step 639, the same client waiting to send a request to the server because (ClientThread) is above the (MaxReq) limit is signaled to wake up any thread. In step 641, the process is shown in FIG.
7 to step 607.

A server management thread process is shown in FIG. The server management thread is
Raised by a timer or signal for thread allocation when the number of unused threads in the pool falls below some reasonably low limit. In step 653, a test is made to determine if more threads need to be added. One suitable test is ((Unused
Threads) <(MinThreads) & (TotalThreads) <(Max
Threads)) or not. If not, then in step 654 the management thread returns to the dormant state. If so, in step 655 ((UnusedThreads)-(Min
Threads)) Communication threads are added to the thread pool according to the formula of adding threads to the pool. At step 657, (UnusedThreads) becomes (MinTh
read)). However, Unuse
Only when dThreads drops below the (MinThreads) limit,
Note that threads will be added immediately. Otherwise, the thread will be delayed until the next timer interval. In step 659, the (TotalThreads) variable is incremented by the number of threads added. The management thread returns to the sleep state in step 654.

FIG. 19 also shows a server management thread method for reducing the number of unused threads in the communication thread pool to improve performance. In step 661, a thread is awakened by a timer that periodically awakens the thread for allocation or deallocation of communication threads. In step 663, a test to determine if there are too many threads in the thread pool, for example, ((ReservedThreads) <
((MinThreads)) &((UnusedThread)> (MinThreads
s)) or not. Otherwise, in step 664 the thread sleeps until the next interval. If so, then in step 665 the number of threads in the pool is reduced by one. In step 667, (TotalThr
eads) is decremented by 1. If no activity occurs during a given period, the (TotalThreads) variable will eventually revert to (MinThread). In step 669, the test determines if there are too few unused threads in the thread pool. (ReservedThreads)>
(TotalThreads) & ((ReservedThreads) <(MaxThre
You can use the expression whether or not ads)). If so, ((ReservedThreads)-(TotalThreads
s)) is added, the thread is added to the thread pool. In step 673, (TotalT
hreads) variable is set to (ReservedThreads). The management thread returns to the sleep state in step 674.

Advantages of the present invention include ingress control of session and normal client requests. In addition, thread resources to service client requests are guaranteed to the client task's permitted limit. Therefore, it never waits for server thread resources to keep the client stalled.

In the case of the pre-allocation thread that can be shared among all clients, the threads are not created or deleted in the thread execution path corresponding to the client request, so the response time to the client request is improved by the performance of the server. It Over-committing is achieved by periodically pruning back the number of allocated threads to (MinThreads) during periods of inactivity.
Minimize thread resources. The total number of server threads in the pool can grow up to the configured value (MaxThreads). Inactive threads are kept to a minimum, so
This reduces system overhead.

Since (MaxThreads) and (MinThreads) are configuration limits and can be made accessible to the system administrator, the present invention achieves dynamic thread resource adjustment. These can be adjusted by manually configuring and adjusting to the minimum value that is optimal for the installation system. Alternatively, keep track of the number of clients and concurrent client requests at various times of the day and automatically (MinThreads) based on these statistics.
You can also calculate and adjust the values for and (MaxThreads).

Multi-threaded client / server
Although the concept of thread pools has been commonly used in the system, no dynamic adjustment of the communication thread pool based on the number of clients and client usage has been done so far. The present invention is equally applicable to serving long-term or short-term client requests.
Moreover, the use of thread pools to implement network protocol servers operating at the user level has not been implemented in the prior art.

The present invention can be implemented in any client / server system where the server is multitasking and must efficiently support a large number of clients. This solution is particularly useful for systems that do not have a lightweight execution unit, such as the IBM mainframe MVS and many UNIX based systems.

As mentioned above, a network protocol server using the above algorithm can be implemented using object oriented techniques by defining a set of network server classes.
An example of the definition of such a class is shown below.

Class TNetworkServer: Public TNetworkThreadHandle {Public: TNetworkServer-class constructor-TNetworkServer-class destructor AddClientPort-add port to client port pool RemoveClientPort-remove port from client port pool AddServerThread-ThreadPool Add a thread to DeleteServerThread-Delete a thread from ThreadPool ExecuteMgmtThread-Manage thread entry ExecuteThread-NetworkThread entry point Private: RegisterNames-Publish server names that should be made available to clients

Network thread class used for network server execution class TNetworkThreadHandle: {Public: TNetworkThreadHandle-class constructor TNetworkThreadHandle-class destructor Fork-join to start a new thread to execute a class function-thread completes Wait until Release-indicates that the thread can delete the object

RPC class for network client / server communication class TNWRPCMessage {Public: virtual TNWRPCMessage (); virtual ~ TNWRPCMessage (); / * Client side method: SendRequest () * / virtual kern_return_t SendRequest (const port_t & clientport, void * buffer, int &buflen); // buffer used for inbound / outbound virtual kern_return_t SendRequest (const port_t & sessionport, port_t & clientport, void * buffer, int &buflen); / * server-side method: ReceiveRequest () & Reply & Receive () * / virtual kern_return_t ReceiveRequest (const port_t & sessionport void * buffer, int &buflen); virtual kern_return_t ReceiveRequest (const port_t & clientport_pool, void * buffer, int & buflen, port_t &clientport); virtual kern_return_t SendReply (const port_t & newclientport, void * buffer, int & buflen, port virtual kern_return_t SendReply (const port_t & clientport, void * buffer, int &buflen);};

Network in client / server environment
Request Representation Here we present an object-oriented representation of network protocol requests for a client / server model.
The protocol API is object-oriented,
When the implementation is also object-oriented, the object-oriented representation of protocol requirements becomes important. Object-based client requests to access network protocols are sent to the server, which delivers those requests to the appropriate network protocol layer objects. The present invention presents a new scheme for forwarding a client network request, delivering the request to the appropriate network protocol layer residing on the server, and retrieving the result of the request to the client application. The client request is wrapped in a "network operation" object, which contains all the information the server needs to be able to submit the request to a network protocol layer object.

Consider the following scenario. The client API contains a set of object oriented network protocol interface requests, where the protocol is implemented as a stack of objects, each object representing a particular OSI layer. The network protocol stack provides various network protocols that reside on the network server and RPC to interact with the client and server.
Alternatively, there is a communication mechanism such as IPC. When a client requests network activity, such as sending some data, the request needs to be forwarded to the appropriate network protocol stack on the server. The present invention presents a unified scheme for forwarding such client requests to the server. Because this scheme utilizes versatility, the process of dispatching such requests and processing them at the server remains the same for any request and protocol stack.

The client interface for accessing the network protocol is mainly TProtoco.
Depending on the lInterface class. This protocol implementation represents each OSI layer based on the TProtocolLayer class. This network subsystem consists of TFamilyLayer objects for each protocol such as TCP / IP and SNA, and TDataLinkLayer objects, both objects resident in the system. A stack of TProtocolLayer objects to represent the session layer, transport layer, and network layer is created for every client endpoint, and the client communication endpoint is described by the TAccessDefinition object. All of these concepts, related classes, and their functionality are described in the Protocol Interface Model section above.

1. Network Operation Object All network requests from the client to the server and vice versa are forwarded using the TNetworkOperation object. TNetworkOperation
The object provides a mechanism for carrying client network requests to the protocol layer within the server and relaying the results from the server to the client.

The TNetworkOperation class is the base class for all requests. TNetworkProtocol for each request that the client interface makes to the server
A subclass is derived from. For each of the TProtocolInterface methods, a corresponding "operation object" class is defined. Figure 20 shows a class hierarchy of class objects for some client requests. TNetworkOperation class 70
1 is at the top of the hierarchy. TConnectOp class 703
, TSendOp class 705 and TReceiveOp class 707
And TDisconnectOp class 709 and TBindOp class 71
All 3 are derived from the base class, TProto
colInterface class connection operation, send operation, receive operation,
Corresponds to disconnection operation and bind operation. GetPeerN
Get and set requests such as ame and GetLocalName are T
It is bundled in one operation class called GetSetNetworkOp class 711.

A TNetworkOperation object is created by TProtocolInterface to satisfy a request that needs to be addressed at the network server. TNetwo
Classes derived from rkOperation represent a particular request from an interface. The TNetworkOperation object is responsible for ensuring that the request is delivered to the appropriate protocol layer.
It is sent to the network server using the RPC / IPC mechanism. When the network server receives the NetworkOperation object, it will
Call the Execute () method and then the corresponding function on the appropriate protocol implementation layer object.

Thus, the TNetworkOperation object has "built-in intelligence" to perform the tasks requested of it. When the network server receives the TNetworkOperation object, it calls the Execute () method in that object. The server functionality is the same regardless of the characteristics of the client request. The Execute () method for each client request contains all the information needed to transfer the client request to the appropriate protocol layer object.

TNetworkOperation object is TProt
You can also create a concrete class of ocolInterface. For example, the default class for TBindOp is TCP
If the TCP / IP interface does not satisfy the TIP / IP request, the TCP / IP interface creates a TTCPBindOp class, TBindOp.
Override. After that, when the client makes a bind request, it represents a concrete TCP / IP client API.
The TTCPINF class creates a TTCPBindOp object.
TN to redefine the meaning of a particular client request or to add a new request and its operation object.
The ability to inherit from the etworkOperation class makes this scheme extremely flexible and powerful.

FIG. 21 illustrates the class hierarchy of class objects created to satisfy a particular client request. TTCPBindOp object 715 of the same figure
Is created by the TTCPTINF :: Bind () method in response to a bind request from a client application. This overrides the TProtocolInterface :: Bind () method. TTCPNew1Op717 and TTCPNew2Op7
19 is TCP / for some client requests.
2 is an example of two new IP-specific operation objects.

[0172] 2. Functions of TNetworkOperation Following are some of the important functions provided by the TNetworkOperation class.

Class Constructor: This function sets the protocol layer index that is the subject of the request by the client application.

The layer index identifies whether the request should be sent to the transport layer, network layer or family layer of the protocol stack.

Execute (): This function calls TNetworkOpera
Called by the server when it receives a tion object. This function gets the layer index from the operation object, collects the relevant parameters from the operation object, and makes a call to the appropriate TProtocolLayer object in the stack. For example, TBindO
p :: Execute () returns a TTCPProtocolAddress object in B
TProtocolLayer :: Bin as a parameter to the ind () function
Should call d ().

Get / SetLayerIndex: This function returns / sets the layer index in the operation object.

SetLocationToClient: By default, the operation object sets its location in the server.
The behavior of the operation object differs depending on whether it is on the server or the client. For example,
TB because it is a parameter to the TProtocolLayer :: Bind () function
indOp needs to send a TNetworkAddress object to the server. However, the server does not have to return the address to the client. Position flags are used to control the passing of parameters. When a network operation object is created by a client, it sets the location on the client.

Stream-out Operator: This function is used to flatten an operation object and put its data members into the data stream.
For example, the Stream-out operator for TBindOp is TNetwo when it sends an object from a client.
Flattens the rkAddress object. TSendOp can flatten the buffer address and TNetworkAddress object to send the buffer and destination address to the server. The server then calls SendOp :: Execute (), which in turn calls TProtocolL with user data.
Call the ayer :: Xmit () method and send the data to the destination. When the transmission is complete, the server uses the RPC / IPC mechanism to return the TSendCompletion object to the client. The Stream-out operator for TSendOp checks if it is a server and streams out a TSendCompletion object.

Stream-in Operator: This function is used to reconstruct an object from the data stream if the object is flattened. It is clear that the operation is the reverse of the Stream-out operator. Manipulation objects use position flags to flatten the object in the data stream and reconstruct the object from the data stream.

3. Client-Server Communication For every user-created communication endpoint, there must be a unique ID that must be maintained to associate the endpoint with the stack of protocol layer objects. The protocol layer object represents an endpoint on the server process. However, note that this correspondence is one-to-one. Therefore, TAccessDefinition :: I
TAcces during endpoint creation using the nstantiate () method
An sOp object is created. The TAccessOp object creates a ClientStackHead object that represents the client side of the communication. Then the TAccessOp object is flattened and RPC or IPC by ClientStackHead
Sent to the server using the mechanism. Then the server is TNet
Use the workOperation stream-in operator to reconstruct the TAccessOp object from the data stream, and then use TAcce
Call the ssOp :: Execute () method. This function creates a ServerStackHead object that creates protocol layer objects from the protocol interface objects and holds a list of pointers to these protocol layer objects in the TServerStackHead object. The TServerStackHead pointer is stored in the network server's global table and the index is streamed out to the client. TClientSta
The ckHead object stores the ServerStackHeadID,
Use it for all subsequent operations. Therefore, Se
The rverStackHeadID functions as a unique ID between the client and the server. Subsequent requests such as TBindOp, when received by the server, use the ID passed in TBindOp to locate the corresponding server stack head.

TClientStackHead and TServerStackHead are
Manages client-server interactions for a given endpoint. These objects link between the TAccessDefinition object, which is the handle of the client endpoint, and the corresponding stack of TProtocolLayer objects that represent the endpoint on the server. Also, ClientStac
The kHead and ServerStackHead pair constitutes an internal management object that links the client and server.

Some of the important functions of TClientStackHead are shown below.

1. ProcessOperation: This function is TC
lProtocolInterface or TAccessDefin for lientStackHead to handle TNetworkOperation objects
Called by the ition object. This function flattens the TNetworkOperation object and sends the flattened operation object to the server using the RPC / IPC mechanism provided by the system. This function is also called by Netw when the server responds to the request sent.
Also rebuild the orkOperation object. Basically this function sends and receives NetworkOperation objects to and from the server.

2. SaveServerInfo: This method
It is called to store ServerStackHeadID in ClientStackHead. When the AccessDefinition is instantiated, the server will be a ServerSt created for the endpoint.
Returns a TAccessOp object with an ID for ackHead. After that, whenever a request is sent to the server, NetworkOperation uses this ID.

3. CancelRequests: This function is called by TProtocolInterfa by the client application.
This is called when ce :: CancelRequests is called or when the client application terminates abnormally. ClientStackHead is a CancelRequest that notifies ServerStackHead to take any necessary cleanup.
Create an sOp operation object.

Some of the important functions of ServerStackHead are shown below.

1. Class Constructor: This constructor takes a stack of TProtocolInterface objects and builds a corresponding TProtocolLayer object. It maintains a pointer to these layer objects to call these layer objects from subsequent requests.

2. ProcessOperation: This function is called by NetworkServerProcess when it receives a NetworkOperation object from the client. This function calls the Execute () method on the TNetworkOperation object after locating the appropriate ProtocolLayer object. Then Execute
The () method calls the required method on the ProtocolLayer object.

[0189] 3. GetProtocolLayer: This function returns a pointer to the indexed TProtocolLayer object. This index is passed by the client application.

4. CancelRequests: This function is called when TCancelRequestsOp is received to cancel all pending requests on the protocol stack. This is the CancelReques from TClientStackHead
This is a server-side function corresponding to ts.

FIG. 22 shows the class hierarchy of the above objects and describes the object model using Booth's notation. TAccessDefinition101
Is derived from TNetworkDefinition100. The TAccessDefinition 101 contains various TProtocolInterface135 objects that make up the endpoints. In addition, TAccessDefinition101 is a TCli that executes all of the primitive functions of client-server communication.
Also includes entStackHead721. TServerStackHead7
Reference numeral 23 is a server-side class corresponding to ClientStackHead. The pair of TClientStackHead and TServerStackHead is
Represents a link between a protocol interface and a protocol implementation layer object, thus linking a client application with a protocol stack on a server. TProtocolInterfa
Both the ce class 135 and the TProtocolLayer class 151 are derived from the common basic class MProtocolService 133. Any network request from the client is sent to the server which is returned by the TNetworkOperation 701 object. That is, TProtocolInt
The method in erface creates the appropriate TNetworkOperation object and the operation object is TClientStackHead
Flattened by and sent to the server. TNetworkOper
ation objects are TClientStackHead and TServerStac
Use both kHeads.

FIG. 23 shows the flow of requests from the client to the server and vice versa. As aforementioned,
The endpoints are represented by a stack of TAccessDefinition objects on the client and TProtocolLayer objects on the server. The interaction between the client and server is the TClientStackHead object and the TServerStack
Managed by the Head object. The figure shows two endpoints 725. The network request from the client is a ServerProcess as a TNetworkOperation object using the system RPC or IPC mechanism.
/ Sent to Thread727. ServerProcess is TNetwork
Reconstruct the Operation object, then T for endpoint 1.
Locate the ServerStackHead object and use the ServerS
Route the request to tackHead1729. Similar processing is done when routing a request from endpoint 2 to ServerStackHead2, which represents this endpoint on the server. Then ServerSt
ack1 calls the TNetworkOperation :: Execute () method, which calls the appropriate method on TTransportLayer on stack 1733. TTransportLayer requests T
You can also choose to call the methods of TNetworkLayer that you want to send to FamilyLayer 737. The family layer then sends a request to the TDataLinkLayer on Stack1 733. TTranspo
rtLayer sends the request to TFamilyLayer 737 TNetworkL
You can also choose to call ayer's methods. After processing the request, the family layer then sends the request to TDataLinkLayer 739, which can send the request to the adapter. DataLink
Upon receiving any packet via the adapter, the Layer dispatches the packet to the family layer. TFamilyLayer routes the packet to the appropriate stack. Returning to the TTransportLayer from the call is T
NetworkOperation :: Execute () collects the response and uses the system's RPC / IPC mechanism to populate the appropriate TClientStack.
Returns a TNetworkOperation object to Head. This procedure consists of endpoint 2 and stack 2 7 which represent the endpoints on the server.
The same is true for any requirements on 35.

FIG. 23 shows the relationship between client and server class objects. In the example below,
A general network client / server model is assumed.

[0194] 3. Example TT representing TCP / IP transport interface
Consider CPTINF. Assume that TTCPTINF :: Bind () takes TTCPAddress as an input parameter and returns a TTCPAddress object. However, TTCPAddress is TPr
Please note that it is derived from otocolAddress. As shown in FIG. 24, the TTCPTINF :: Bind () method executes as follows.

At step 801, TNetworkOperation is executed.
An object, TTCPBindOp, is created.

At step 803, this AccessDefiniti
Acquire the ClientStackHead object for on.

In step 805, ClientStackHead :: ProcessOperation () is called to flatten the TTCPAddress of the TTCPBindOp object and send the request to the server. The server flattens the TTCPBindOp from the message stream such as RPC / IPC in step 807.
To rebuild.

At step 809, the server sends TTCPBind.
ServerStac from the stack ID passed in the Op object
Locate the kHead object.

At step 811, the ServerStackHead object is TProto to the appropriate protocol layer object.
Call colLayer :: Bind ().

At step 813, the call to bind returns a TTCPAddress object, and the server calls TTC.
Restore the return information (address) with PBindOp and return it to the client in a stream. ClientStackHead reconstructs a TTCPBindOp () object from the message stream. Finally, in step 817, TTCPINF :: Bin
d () retrieves TTCPAddress from TTCPBindOp and returns it to the client program.

Although the present invention has been shown and described with respect to particular embodiments, those skilled in the art will recognize that the invention can be modified and practiced in other environments. For example,
While the present invention described above may be conveniently implemented on a general-purpose computer that is selectively reconfigured or activated by software, those skilled in the art will include specialized devices specifically designed to carry out the invention. It should be noted that the present invention can be implemented in hardware, firmware, or a combination of software, firmware and hardware. Therefore, changes in form and detail may be made without departing from the spirit and scope of the invention as claimed.

As a summary, the following matters will be disclosed regarding the configuration of the present invention.

(1) In a method for dynamically managing a pool dedicated to a communication process between a client process and a server process in an execution unit in a server system, a method typically used in the communication process pool Allocating the minimum number of execution units needed to support a typical client load, and the maximum number to support peak client loads without overloading the server system And a step in which the server system receives a service request by a client, and for each client request received, assigning an execution unit to the received client request results in a maximum number of execution units in the current communication process pool. Determine whether it will exceed the number of execution units Rejecting a client request if more than, and assigning an execution unit to the received client request results in the current number of execution units assigned to the client task making the request of the assigned execution units for the client task. If the decision step is negative, the client request is accepted, so that the execution unit in the communication process pool can request the client request. And a step assigned to. (2) In a system for dynamically managing a pool dedicated to a communication process between a client process and a server process in an execution unit in the server system, a typical client is included in the communication process pool. A minimum number of execution units needed to support the load, and a maximum number of execution units to support the peak client load without overloading the server system, and the client Of how the server system receives service requests by and how the execution units assigned to the received client requests determine whether the current number of execution units in the communication process pool will exceed the maximum number of execution units. And the execution unit assigned to the received client request. Means for determining whether the current number of execution units assigned to the requesting client task will exceed the number of assigned execution units for the client task, and in the communication process pool. And a means for permitting the client request when the determining means confirms that the execution unit of the above can be assigned to the client request. (3) In a computer program product on a computer-readable medium for dynamically managing a pool of execution units in a server system dedicated to a communication process between a client process and a server process, The minimum number needed to support a typical client load in the communication process pool, and an upper limit to support a peak client load without overloading the server system. Means for instructing the system to allocate the maximum number of execution units, means for instructing the system to receive service requests by clients from the server system, and assigning execution units to received client requests, The maximum number of current execution units in the pool A means of instructing the system to determine if there will be more than a line unit, and assigning an execution unit to a received client request will result in the client having the current number of execution units assigned to the requesting client task. Means to instruct the system to determine if the number of assigned execution units for the task will be exceeded, and to respond to the determination that execution units in the communication process pool can be assigned to client requests. And means for instructing the system to authorize the client request.

[Brief description of drawings]

FIG. 1 is a computer constructed in accordance with the teachings of the present invention.
It is a figure showing a system.

FIG. 2 illustrates a class hierarchy for network definition objects.

FIG. 3 shows a class hierarchy for network address classes.

FIG. 4 is a diagram showing a class hierarchy for protocol interface classes.

FIG. 5 illustrates a class hierarchy for protocol layer classes.

FIG. 6 is a state diagram of connection-oriented transition.

FIG. 7 is a state diagram of a non-connection state transition.

FIG. 8 is a diagram showing class relationships in a TCP / IP embodiment of the present invention.

FIG. 9 is a flow chart of a process for setting up a network connection according to the present invention.

10 is a systematic diagram of various objects in the dedicated network layer of the network connection process shown in FIG.

FIG. 11 shows a class hierarchy for network event objects.

FIG. 12 is a flow diagram of a process for collecting events from a single communication endpoint.

FIG. 13 is a flow diagram of a process for collecting events from multiple communication endpoints.

FIG. 14 is a systematic diagram of first and second embodiments for managing a pool of communication threads for processing network protocol server client requests.

FIG. 15 is a systematic diagram of first and second embodiments for managing a pool of communication threads for processing client requests of a network protocol server.

FIG. 16 is a flow diagram of a management process for a pool of communication threads.

FIG. 17 is a flow diagram of a management process for a pool of communication threads.

FIG. 18 is a flow diagram of a management process for a pool of communication threads.

FIG. 19 is a flow diagram of a management process for a pool of communication threads.

FIG. 20 is a class hierarchy diagram for a network operation object.

FIG. 21 is a class hierarchy diagram for a network operation object.

FIG. 22 is a diagram showing class relationships between various classes of the present invention.

FIG. 23 shows a message flow between various objects in a network according to the present invention.

FIG. 24 is a flow chart for passing a network protocol request in a network operation object.

[Explanation of symbols]

 11 system unit 12 keyboard 13 mouse 14 graphic display 15A speaker 15B speaker 21 system bus 22 microprocessor 23 ROM 24 RAM 25 memory management chip 26 hard disk drive 27 floppy disk drive 28 keyboard controller 29 mouse control Device 30 Video controller 31 Audio controller 32 CD-ROM 33 Digital signal processor 40 Input / output controller 46 Network 48 Operating system 49 Client application 50 Client interface 51 Protocol object 52 Server application

 ─────────────────────────────────────────────────── —————————————————————————————————————————————————— Inventor Leo Yue Tak Jung United States 78759 Austin, Texas Decay Ranch Road 11714

Claims (3)

[Claims] 1. A method for dynamically managing a pool of execution units in a server system dedicated to a communication process between a client process and a server process, the method comprising: Allocating the minimum number of execution units required to support a large client load, and the maximum number of execution units to support a peak client load without overloading the server system. , The server system receiving service requests by the client, and for each client request received, assigning an execution unit to the received client request, the maximum number of execution units currently in the communication process pool is reached. Determine whether the number of execution units Rejecting a client request when spinning and assigning an execution unit to a received client request causes the current number of execution units assigned to the client task making the request to be the number of assigned execution units for the client task. If the decision step is negative, the client request is accepted, so that the execution unit in the communication process pool can request the client request. And a step assigned to. 2. A system for dynamically managing a pool of execution units in a server system dedicated to a communication process between a client process and a server process, typically in the communication process pool. A minimum number of execution units needed to support a large client load, and a maximum number of execution units to support a peak client load without overloading the server system. , The means by which the server system receives service requests by clients, and whether assigning an execution unit to a received client request causes the current number of execution units in the communication process pool to exceed the maximum number of execution units. Means for determining the execution unit for the received client request Means to determine whether the current number of execution units assigned to the requesting client task exceeds the number of assigned execution units for the client task, and a communication process pool. And a means for permitting the client request when the determining means confirms that the execution unit in the can be assigned to the client request. 3. A computer program product on a computer readable medium for dynamically managing a pool of execution units in a server system dedicated to a communication process between a client process and a server process. , The minimum number needed to support a typical client load in the communication process pool, and an upper limit to support a peak client load without overloading the server system. A means to instruct the system to allocate a maximum number of execution units, a system to instruct the server system to receive a service request by the client, and an allocation of execution units to the received client request The current number of execution units in the process pool A means of instructing the system to determine if it will exceed a large number of execution units, and assigning an execution unit to a received client request will result in the current number of executions assigned to the client task making the request. A means to instruct the system to determine if a unit will exceed the number of assigned execution units for a client task, and that execution units in the communication process pool can be assigned to client requests. Means for instructing the system to authorize the client request in response to the determination.