CA2237742A1 - A system resource reduction tool utilizing tcp/ip socket applications - Google Patents
A system resource reduction tool utilizing tcp/ip socket applications Download PDFInfo
- Publication number
- CA2237742A1 CA2237742A1 CA 2237742 CA2237742A CA2237742A1 CA 2237742 A1 CA2237742 A1 CA 2237742A1 CA 2237742 CA2237742 CA 2237742 CA 2237742 A CA2237742 A CA 2237742A CA 2237742 A1 CA2237742 A1 CA 2237742A1
- Authority
- CA
- Canada
- Prior art keywords
- data
- receipt
- command
- token
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000009467 reduction Effects 0.000 title description 2
- 238000012545 processing Methods 0.000 claims abstract description 39
- 230000007246 mechanism Effects 0.000 claims abstract description 17
- 238000012546 transfer Methods 0.000 claims abstract description 7
- 238000000034 method Methods 0.000 claims description 91
- 230000008569 process Effects 0.000 claims description 47
- 238000004891 communication Methods 0.000 claims description 40
- 230000006870 function Effects 0.000 claims description 37
- 238000003672 processing method Methods 0.000 claims 2
- 230000026676 system process Effects 0.000 claims 2
- 230000001934 delay Effects 0.000 abstract 1
- 230000000903 blocking effect Effects 0.000 description 19
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 230000008520 organization Effects 0.000 description 1
Landscapes
- Communication Control (AREA)
Abstract
The present invention presents a new way of data transfer in a multi-host computer environment without causing unnecessary system idle time or other processing delays by utilizing an activate_on_receipt mechanism. This mechanism sets aside a temporary storage upon receiving certain commands such as a read which may tie-up system resources until the incoming data is received. The system environment then proceeds with performing other operations until the first bytes of incoming requested data is received at the temporary storage location, at which time the mechanism terminates all running operations in favor of processing the data that is being received. If the size of the requested temporary storage location is accommodating to the size of the incoming data, data is directly read. Otherwise a new storage location is obtained and the data copied and fully received at this new location before it is read.
Description
CA 02237742 1998-0~-14 A SYSTEM RESOURCE REDUCTION TOOL
UTILIZING TCP/IP SOCKET APPLICATIONS
FIELD OF INVENTION
This invention is directed to a tool designed for reducing resources utilized by a system while processing certain commands such as a read function issued during a communication session such as during a TCP/IP socket application.
BACKGROUND OF THE INVENTION
In a host system network or other similar multi-host computer environments, a number of processors and hosts co-exist that can simultaneously request and access data or run different resident applications. In such environments data processing systems are employed to m~int~in data needed in different locations throughout the environment to service the processing of dirrelelll applications. This allows the presentation of a single image to the remote host or user and allows workload balancing by the processor complexes. The data may be m~int~ined in one or more host systems linked to the remote hosts and to other host systems forming a network of communication links in the environment. In order to send messages from one host on the link to another host on the link, communication rules called protocols are established to control the communication by routing messages and accessing appropriate host computers on the link in the complex or the environment. These communications protocols typically exist as part of a teleprocessing architecture that defines the function and structure of data communication products.
In such computer networks or environments, an application program interface (hereinafter an API) is also provided which is a functional interface supplied by one or more operating systems allowing an application program written in a high-level l~gllflge to use specific data or functions CA 02237742 1998-0=,-14 of the operating system. In some instances an API acts as the interface through which an application program interacts with an access method. In a multi-tasking operating system, application program requests are made to the operating system through the API so that a request automatically starts a task or a process to be completed.
In parallel processing environments, the computer architecture uses many interconnected processors to access large amounts of data in order to simultaneously process a large number of tasks at high speeds. In such environments, the multi-tasking operating system relies heavily on the API for timely task processing.
To perform the required task processing in a timely manner, many API's define a set of collective operations for performing complex communications between the groups of processes.
There are several advantages associated with collective operations, among which are ease of use and performance. There is, however, one major disadvantage with the use of collective operations. In most instances, many of these collective operations are synchronous, and they "block" the processor until it is time for the performance of the task; hence known as "blocking"
operations. The solution for applications whose tasks are not inherently synchronized is to use "non-blocking" or asynchronous collective operations. Non-blocking operations allow each task to proceed at its own pace, and could periodically be tested for completion or "waited" for if necessary. But non-blocking operations also have certain disadvantages. For example, when a wait is necessary or when an internal dependency is encountered, the control has to be returned to the user for decision m~king This is because in non-blocking environments where asynchronous collective operations are used, the operation as a whole is not allowed to "block" any of the tasks or processor time. Because of this dependency, no single stage of the process can block the operation.
CA 02237742 1998-0~-14 But returning the control to the user is only one portion of the problem. One main concern after the control has been returned to the user is the issue of notifying when the operation can be resumed, as in when the original internal dependency has been resolved. A second related issue is to return to the same processing location just before the interruption occurred once the user decides to resume the operation.
Another related and common problem that occurs both with the blocking and non-blocking operations is resolving performance issues and system idle time. Certain commands such as a read() or a recvfrom() call, require the system environment to temporarily suspend processing operations until data for the read or receive command is received by the requesting application. When the data is not immediately available for processing, most of the resources available to the application assume a suspended state and no further processing becomes available until the data becomes available. In blocking mode, the sequentiality of command processing forces the entire process environment to wait for the incoming data before the next stage of command processing can be performed. In non-blocking mode, still when the data is not immediately available, either the process environment has to keep checking such availability and hence turning the asynchronous operation into a synchronous operation or it has to terminate the operation and return the control to the user which causes further problems. In a high performance, transaction oriented system, it is possible that many processes become suspended all at one time as a result of such data unavailability. Consequently, the system can runout of resources without the possibility of any new processes being dispatched.
SUMMARY OF THE INVENTION
An object of the present invention is to increase system availability and performance.
CA 02237742 1998-0~-14 Another object of the present invention is to allow an operating system to handle a large number of transactions without the need to shut down the system due to system constraints.
In a multi-host computer environment with a plurality of processors and at least one central memory, where the hosts use communication processors such as TCP/IP to communicate with one another, data transfers can cause entire system operating suspension and idle time. The present invention employs an activate on_receipt mechanism for issuing an activate on_receipt function call upon receipt of a command from one of the processors that requires receipt of data before processing can be resumed. A small temporary storage location is then allocated for receipt of a portion of incoming data to be received. Several parameters are also passed to identify and associate the data once received with the requesting application, processor and communication session. The system environment can in the meantime proceed with its normal processing operations until such time when the first bytes of the incoming data are received. In one embodiment, the original process is officially terminated and resources are freed. In another embodiment, once the first bytes are received, the activate_on_receipt mechanism terminates any running process in favor of creating a new process to handle the incoming data. If the incoming data is longer than the temporarily allocated storage location, a new location is set aside to accommodate the data before the rem~ining bits are received and data read. Otherwise the data is read from the temporary location and no new storage location is allocated.
In a computer system having at least one residence operating system, a data processing tool is introduced. The tool first issuing a special interface function call upon receipt of a read/receipt command. The system can then return or continue with other operations while the operating system will save the program name and token associated with any application or processor issuing the particular read/receive command. A socket descriptor to identify any data communication protocols is then created. In addition, a system control table entry is also created, having a file descriptor for saving the program name and token information in a data structure CA 02237742 1998-0~-14 format and associating them with said socket descriptor. Once the data arrives this system control table is located and the requesting application or processor is identified by way of finding the information stored about the whereabouts of the socket descriptor. A new process is then created to process the newly arrived data after obtaining the name of the requesting program and finally the read/receive command is processed.
BRIEF DESCRIPTION OF THE DRAWINGS
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of practice, together with further objects and advantages thereof, may best be understood by reference to the following description taken in connection with the accompanying drawings in which:
Figure 1 is a block diagram showing conceptual layering of communication protocols used;
Figure 2 is a flow chart diagram of an overview of the present invention; and Figure 3 is a flow chart diagram of a particular embodiment of the present invention.
DETAILED DESCRIPTIO~ OF THE INVENTION
When several hosts and/or remote hosts are connected in a computer network, a need arises to set up and maintain communications between them. In order to make communication possible, the network of host systems comprise communication links where different kinds of host computers are connected to those links. In order for messages to be sent from one host on the CA 02237742 1998-0~-14 link to another host on the link, rules called protocols are established to control the communication links, route messages, and access appropriate host computers on the link.
The communication protocols can be conceptually viewed as being layered, as depicted in Figure 1, with each protocol layer making use of the services provided by the layer beneath it.
The lowest layer is the Link layer 102 which deals at the hardware level and controls the transmission of data between hosts on a single network of a particular type. The next higher layer is the Machine-to-Machine (MM) layer 104 which provides the capability to communicate between hosts that are not directly connected to the same physical complex. A widely used example of this layer is an Internet Protocol (IP). Internet IP is a standard industry communication protocol which allows the use of standard software communication packages.
The next higher layer of protocol is the Port-to-Port (PP) layer 106 that allows multiple processes executing different application programs to communicate with remote processes at remote hosts all at the same time. The PP layer uses the MM protocol layer to transfer data between host machines. The PP layer presents an interface to the application layer which allocates a local communication port to a process, connects that port to a remote port on a remote host, and transfers data between the local port and the remote port. Examples of such PP
transport protocols are TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and XNS (Xerox Network System). TCP is capable of operating with devices using IP suite of protocol (TCP/IP).
The highest level is the Application level 108. The API's also reside at this level. In addition other communication applications such as the socket applications reside at this level. A
socket application is a unique host identifier created by the concatenation of port identifiers with TCP/IP or other communication sessions addresses.
CA 02237742 1998-0~-14 While running any high level application especially a socket application, certain type of commands can cause processing disruption or temporary pending of resources. This is usually the case when the data is not immediately available. For example, TCP protocol utilizes a read() command in order to access data. UDP protocol uses a similar command recv()/recvfrom() function call which is very similar to the TCP protocol's read() command. ln either case when a read(),recv() or recvfrom() command is used, a large portion of the memory is immediately allocated and set aside by the processor in anticipation of the incoming data. This allocated block of memory usually known as the maximum length or Max data length can range anywhere between 32K to 2 Megs.
When the data is not received immediately, most of the resources available to the application assume a suspended state and no further processing is allowed until data becomes available. In a high performance system this can cause possible suspension of many processes concurrently. This system or processor unavailability is created regardless of whether the system is running blocking or non-blocking collective operations as described in detail below.
A) Blocking Operations When the application or the system is running in blocking mode the processing operations are performed in a synchronous mode. When a read(), recv() or recvfrom() command is issued, but data does not become immediately available and since the system as a whole is running synchronously, all threads have to sit idle until the time when the data bytes finally come in. No further processing is possible until the time when the data becomes available. Furthermore, since a large portion of memory has to be allocated for the receipt of the data, the system environment as a whole can be affected.
CA 02237742 1998-0=,-14 B) Non-Blockin~ Operations While running a non-blocking operation, the system's processing is asynchronous and therefore after a data read/receive command is issued the process does not sit idly in the same sense as in a blocking operation. Nonetheless, the operation of the process as a whole prior to the receipt of the data is very similar as to the time when it is running in blocking mode. In a non-blocking mode, each time the system checks for the availability of the data to be read and finds out that the data is still unavailable it has to make a decision. This decision is either to keep checking for the availability of data on a continuous basis which creates a situation almost identical to that of a blocking operation, or it has to reassign the allocated memory space by killing and recreating the space allocation needed for continuous operation of the now-idle processors.
In either case, blocking or non-blocking, the maximum length (Max data length), or the memory allocated for the receipt of the data creates a big problem in the continuous availability of the resources available within a high performance transactional process system.
The present invention solves the above problem through an activate_on_receipt mechanism. As shown in FIG. 2, upon the receipt of a read(), recv(), recvfrom() or other similar function calls or commands shown at (202), the present invention issues a new function call (API) called an activate on_receipt() command (204). Basically, this new function call allows the operation of the process to continue as if no command was issued (206), so that the original process is running until the time when the first bytes of data arrive. In certain situations, however, it may be necessary to actually terminate the process after a read/receive was issued. In an alternate embodiment of the present invention, this issue is resolved. In such cases, the process that is started by the original issuance of read/receive must be first terminated so as to free up the resources. However, the activate_on receipt() command call will continue obtaining the requested data despite such termination and upon the arrival of data, a new process will be CA 02237742 1998-0~-14 created as in the previous case. In either case, a temporary storage location (208), preferably of 4K, is allocated in the memory to receive at least a portion of the incoming data. This allows a small area of the memory to be set aside for receipt of such data as opposed to the prior art that uses a large portion of up to 2 Megs. In addition, the original 4K of memory is allocated each time by the system itself rather than by the processor, which will utilize space and memory availability more efficiently. This is because the system can allocate areas in any available pocket since it has a better view of such availability than any of the processors alone.
With each activate_on receipt() call several parameters are also passed (205) to make later processing possible. As shown in FIG. 3, the parameters passed are the socket descriptor, the program name pointer and the token pointer to later identify the application and host issuing the command or the call (330). The socket descriptor is an integer obtained by the application from a prior socket() API function call and is associated with the application's half of the TCP/IP
or other similar protocol's data communication session (332). The program name pointer contains the address of the program name that is entered when data arrives in the host from the other half of the protocol's data communications. The token pointer contains the address of an 8 byte token that contains data that the application is passing between processes.
After the socket application issues the activate on_receipt () function call, the operating system saves the program name and the 8 byte token in a data structure associated with the socket descriptor called a file descriptor (334). After the data starts to come in, the operating system then converts the activate_on_receipt() to a read() or recvfrom() function call. If the activate_on_receipt() was issued for a stream or a connection oriented (TCP) socket, the system then converts the activate_on receipt() function call to a read() function call. If the activate_on receipt() was issued for a datagram or connectionless (UDP) socket, the system converts the activate on receipt() function call to a recvfrom() function call. Either read() or recvfrom() is issued to TCP/IP stack with maximum length (of 32K or more request).
CA 02237742 1998-0=,-14 The mechanism is notified when the first bytes of data arrive as shown in FIG.2 at (210-212). The mechanism then determines if the temporary storage location allocated is accommodating in size with that of the incoming data.
When the data received is less than or equal to the 4K allocated space, no further space will be assigned to receive the remainder of the data to be received. However when the data is longer than 4K more space will be allocated to accommodate the entire data to be received (216).
Upon the receipt of the first data bytes in the allocated location, the activate_on_receipt() command either "activates" the system in that it terminates the original process and/or creates a new process in the host. The data is then read, processed or transferred (213). (After the data arrives7 the system may need to obtain a new storage area and copy the data to this new storage area (218). Subsequently once data is received the function call can then be performed (220-222).) This process is performed in detail in the following manner:
As shown in FIG. 3, the file descriptor is then used to locate the system control table where the program name and 8 byte token that had been saved previously as well as the socket descriptor associated with this TCP/IP socket (338). The system copies the socket descriptor, 8 byte token, the address of the storage block, and the length of the data obtained from an internal header, to another control block associated with a new process that is to be created by the system.
If the file descriptor indicates that the message is received from a datagram socket, the system copies the source address of the message from the internal header to the block associated with the new process. The system then creates the new process (339) and enters the program whose name was obtained from the file descriptor.
CA 02237742 1998-0~-14 To obtain the data7 the new program issues a standard read(), recv(), or recvfrom() socket API function call using the data passed to it by the system in the process. This function call is not sent to the TCP/IP or other similar protocol's stack because the system knows the system already has the data from the network. The purpose of this second read(), recv() or recvfrom() function call is to enable the program to obtain the data from its own buffer or from the buffer obtained by the operating system. After the application has issued the read(), recv() or recvfrom() function call, the system returns the data to the application in the buffer specified by the application.
In a preferred embodiment of the present invention, when the data is larger than the 4K of allocated space, after the first bytes of data are received in the allocated space, in order to obtain the data a read(), recv() or recvfrom() command is issued shown at (345), which allocates the maximum length or other appropriately lengthy space for the transfer and/or copying of the incoming data. However, if the incoming data is to be contained in the 4K of space originally allocated, another activate on receipt() command is issued instead of the read(), recv() or recvfrom() command of the previous case, shown at (350). This second activate_on_receipt function call allows the processing of the data by the system in the allocated 4K of memory without the need to further allocate more memory spaces. In other words, no maximum length space is then allocated to accommodate the copying of a longer data byte.
While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.
UTILIZING TCP/IP SOCKET APPLICATIONS
FIELD OF INVENTION
This invention is directed to a tool designed for reducing resources utilized by a system while processing certain commands such as a read function issued during a communication session such as during a TCP/IP socket application.
BACKGROUND OF THE INVENTION
In a host system network or other similar multi-host computer environments, a number of processors and hosts co-exist that can simultaneously request and access data or run different resident applications. In such environments data processing systems are employed to m~int~in data needed in different locations throughout the environment to service the processing of dirrelelll applications. This allows the presentation of a single image to the remote host or user and allows workload balancing by the processor complexes. The data may be m~int~ined in one or more host systems linked to the remote hosts and to other host systems forming a network of communication links in the environment. In order to send messages from one host on the link to another host on the link, communication rules called protocols are established to control the communication by routing messages and accessing appropriate host computers on the link in the complex or the environment. These communications protocols typically exist as part of a teleprocessing architecture that defines the function and structure of data communication products.
In such computer networks or environments, an application program interface (hereinafter an API) is also provided which is a functional interface supplied by one or more operating systems allowing an application program written in a high-level l~gllflge to use specific data or functions CA 02237742 1998-0=,-14 of the operating system. In some instances an API acts as the interface through which an application program interacts with an access method. In a multi-tasking operating system, application program requests are made to the operating system through the API so that a request automatically starts a task or a process to be completed.
In parallel processing environments, the computer architecture uses many interconnected processors to access large amounts of data in order to simultaneously process a large number of tasks at high speeds. In such environments, the multi-tasking operating system relies heavily on the API for timely task processing.
To perform the required task processing in a timely manner, many API's define a set of collective operations for performing complex communications between the groups of processes.
There are several advantages associated with collective operations, among which are ease of use and performance. There is, however, one major disadvantage with the use of collective operations. In most instances, many of these collective operations are synchronous, and they "block" the processor until it is time for the performance of the task; hence known as "blocking"
operations. The solution for applications whose tasks are not inherently synchronized is to use "non-blocking" or asynchronous collective operations. Non-blocking operations allow each task to proceed at its own pace, and could periodically be tested for completion or "waited" for if necessary. But non-blocking operations also have certain disadvantages. For example, when a wait is necessary or when an internal dependency is encountered, the control has to be returned to the user for decision m~king This is because in non-blocking environments where asynchronous collective operations are used, the operation as a whole is not allowed to "block" any of the tasks or processor time. Because of this dependency, no single stage of the process can block the operation.
CA 02237742 1998-0~-14 But returning the control to the user is only one portion of the problem. One main concern after the control has been returned to the user is the issue of notifying when the operation can be resumed, as in when the original internal dependency has been resolved. A second related issue is to return to the same processing location just before the interruption occurred once the user decides to resume the operation.
Another related and common problem that occurs both with the blocking and non-blocking operations is resolving performance issues and system idle time. Certain commands such as a read() or a recvfrom() call, require the system environment to temporarily suspend processing operations until data for the read or receive command is received by the requesting application. When the data is not immediately available for processing, most of the resources available to the application assume a suspended state and no further processing becomes available until the data becomes available. In blocking mode, the sequentiality of command processing forces the entire process environment to wait for the incoming data before the next stage of command processing can be performed. In non-blocking mode, still when the data is not immediately available, either the process environment has to keep checking such availability and hence turning the asynchronous operation into a synchronous operation or it has to terminate the operation and return the control to the user which causes further problems. In a high performance, transaction oriented system, it is possible that many processes become suspended all at one time as a result of such data unavailability. Consequently, the system can runout of resources without the possibility of any new processes being dispatched.
SUMMARY OF THE INVENTION
An object of the present invention is to increase system availability and performance.
CA 02237742 1998-0~-14 Another object of the present invention is to allow an operating system to handle a large number of transactions without the need to shut down the system due to system constraints.
In a multi-host computer environment with a plurality of processors and at least one central memory, where the hosts use communication processors such as TCP/IP to communicate with one another, data transfers can cause entire system operating suspension and idle time. The present invention employs an activate on_receipt mechanism for issuing an activate on_receipt function call upon receipt of a command from one of the processors that requires receipt of data before processing can be resumed. A small temporary storage location is then allocated for receipt of a portion of incoming data to be received. Several parameters are also passed to identify and associate the data once received with the requesting application, processor and communication session. The system environment can in the meantime proceed with its normal processing operations until such time when the first bytes of the incoming data are received. In one embodiment, the original process is officially terminated and resources are freed. In another embodiment, once the first bytes are received, the activate_on_receipt mechanism terminates any running process in favor of creating a new process to handle the incoming data. If the incoming data is longer than the temporarily allocated storage location, a new location is set aside to accommodate the data before the rem~ining bits are received and data read. Otherwise the data is read from the temporary location and no new storage location is allocated.
In a computer system having at least one residence operating system, a data processing tool is introduced. The tool first issuing a special interface function call upon receipt of a read/receipt command. The system can then return or continue with other operations while the operating system will save the program name and token associated with any application or processor issuing the particular read/receive command. A socket descriptor to identify any data communication protocols is then created. In addition, a system control table entry is also created, having a file descriptor for saving the program name and token information in a data structure CA 02237742 1998-0~-14 format and associating them with said socket descriptor. Once the data arrives this system control table is located and the requesting application or processor is identified by way of finding the information stored about the whereabouts of the socket descriptor. A new process is then created to process the newly arrived data after obtaining the name of the requesting program and finally the read/receive command is processed.
BRIEF DESCRIPTION OF THE DRAWINGS
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of practice, together with further objects and advantages thereof, may best be understood by reference to the following description taken in connection with the accompanying drawings in which:
Figure 1 is a block diagram showing conceptual layering of communication protocols used;
Figure 2 is a flow chart diagram of an overview of the present invention; and Figure 3 is a flow chart diagram of a particular embodiment of the present invention.
DETAILED DESCRIPTIO~ OF THE INVENTION
When several hosts and/or remote hosts are connected in a computer network, a need arises to set up and maintain communications between them. In order to make communication possible, the network of host systems comprise communication links where different kinds of host computers are connected to those links. In order for messages to be sent from one host on the CA 02237742 1998-0~-14 link to another host on the link, rules called protocols are established to control the communication links, route messages, and access appropriate host computers on the link.
The communication protocols can be conceptually viewed as being layered, as depicted in Figure 1, with each protocol layer making use of the services provided by the layer beneath it.
The lowest layer is the Link layer 102 which deals at the hardware level and controls the transmission of data between hosts on a single network of a particular type. The next higher layer is the Machine-to-Machine (MM) layer 104 which provides the capability to communicate between hosts that are not directly connected to the same physical complex. A widely used example of this layer is an Internet Protocol (IP). Internet IP is a standard industry communication protocol which allows the use of standard software communication packages.
The next higher layer of protocol is the Port-to-Port (PP) layer 106 that allows multiple processes executing different application programs to communicate with remote processes at remote hosts all at the same time. The PP layer uses the MM protocol layer to transfer data between host machines. The PP layer presents an interface to the application layer which allocates a local communication port to a process, connects that port to a remote port on a remote host, and transfers data between the local port and the remote port. Examples of such PP
transport protocols are TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and XNS (Xerox Network System). TCP is capable of operating with devices using IP suite of protocol (TCP/IP).
The highest level is the Application level 108. The API's also reside at this level. In addition other communication applications such as the socket applications reside at this level. A
socket application is a unique host identifier created by the concatenation of port identifiers with TCP/IP or other communication sessions addresses.
CA 02237742 1998-0~-14 While running any high level application especially a socket application, certain type of commands can cause processing disruption or temporary pending of resources. This is usually the case when the data is not immediately available. For example, TCP protocol utilizes a read() command in order to access data. UDP protocol uses a similar command recv()/recvfrom() function call which is very similar to the TCP protocol's read() command. ln either case when a read(),recv() or recvfrom() command is used, a large portion of the memory is immediately allocated and set aside by the processor in anticipation of the incoming data. This allocated block of memory usually known as the maximum length or Max data length can range anywhere between 32K to 2 Megs.
When the data is not received immediately, most of the resources available to the application assume a suspended state and no further processing is allowed until data becomes available. In a high performance system this can cause possible suspension of many processes concurrently. This system or processor unavailability is created regardless of whether the system is running blocking or non-blocking collective operations as described in detail below.
A) Blocking Operations When the application or the system is running in blocking mode the processing operations are performed in a synchronous mode. When a read(), recv() or recvfrom() command is issued, but data does not become immediately available and since the system as a whole is running synchronously, all threads have to sit idle until the time when the data bytes finally come in. No further processing is possible until the time when the data becomes available. Furthermore, since a large portion of memory has to be allocated for the receipt of the data, the system environment as a whole can be affected.
CA 02237742 1998-0=,-14 B) Non-Blockin~ Operations While running a non-blocking operation, the system's processing is asynchronous and therefore after a data read/receive command is issued the process does not sit idly in the same sense as in a blocking operation. Nonetheless, the operation of the process as a whole prior to the receipt of the data is very similar as to the time when it is running in blocking mode. In a non-blocking mode, each time the system checks for the availability of the data to be read and finds out that the data is still unavailable it has to make a decision. This decision is either to keep checking for the availability of data on a continuous basis which creates a situation almost identical to that of a blocking operation, or it has to reassign the allocated memory space by killing and recreating the space allocation needed for continuous operation of the now-idle processors.
In either case, blocking or non-blocking, the maximum length (Max data length), or the memory allocated for the receipt of the data creates a big problem in the continuous availability of the resources available within a high performance transactional process system.
The present invention solves the above problem through an activate_on_receipt mechanism. As shown in FIG. 2, upon the receipt of a read(), recv(), recvfrom() or other similar function calls or commands shown at (202), the present invention issues a new function call (API) called an activate on_receipt() command (204). Basically, this new function call allows the operation of the process to continue as if no command was issued (206), so that the original process is running until the time when the first bytes of data arrive. In certain situations, however, it may be necessary to actually terminate the process after a read/receive was issued. In an alternate embodiment of the present invention, this issue is resolved. In such cases, the process that is started by the original issuance of read/receive must be first terminated so as to free up the resources. However, the activate_on receipt() command call will continue obtaining the requested data despite such termination and upon the arrival of data, a new process will be CA 02237742 1998-0~-14 created as in the previous case. In either case, a temporary storage location (208), preferably of 4K, is allocated in the memory to receive at least a portion of the incoming data. This allows a small area of the memory to be set aside for receipt of such data as opposed to the prior art that uses a large portion of up to 2 Megs. In addition, the original 4K of memory is allocated each time by the system itself rather than by the processor, which will utilize space and memory availability more efficiently. This is because the system can allocate areas in any available pocket since it has a better view of such availability than any of the processors alone.
With each activate_on receipt() call several parameters are also passed (205) to make later processing possible. As shown in FIG. 3, the parameters passed are the socket descriptor, the program name pointer and the token pointer to later identify the application and host issuing the command or the call (330). The socket descriptor is an integer obtained by the application from a prior socket() API function call and is associated with the application's half of the TCP/IP
or other similar protocol's data communication session (332). The program name pointer contains the address of the program name that is entered when data arrives in the host from the other half of the protocol's data communications. The token pointer contains the address of an 8 byte token that contains data that the application is passing between processes.
After the socket application issues the activate on_receipt () function call, the operating system saves the program name and the 8 byte token in a data structure associated with the socket descriptor called a file descriptor (334). After the data starts to come in, the operating system then converts the activate_on_receipt() to a read() or recvfrom() function call. If the activate_on_receipt() was issued for a stream or a connection oriented (TCP) socket, the system then converts the activate_on receipt() function call to a read() function call. If the activate_on receipt() was issued for a datagram or connectionless (UDP) socket, the system converts the activate on receipt() function call to a recvfrom() function call. Either read() or recvfrom() is issued to TCP/IP stack with maximum length (of 32K or more request).
CA 02237742 1998-0=,-14 The mechanism is notified when the first bytes of data arrive as shown in FIG.2 at (210-212). The mechanism then determines if the temporary storage location allocated is accommodating in size with that of the incoming data.
When the data received is less than or equal to the 4K allocated space, no further space will be assigned to receive the remainder of the data to be received. However when the data is longer than 4K more space will be allocated to accommodate the entire data to be received (216).
Upon the receipt of the first data bytes in the allocated location, the activate_on_receipt() command either "activates" the system in that it terminates the original process and/or creates a new process in the host. The data is then read, processed or transferred (213). (After the data arrives7 the system may need to obtain a new storage area and copy the data to this new storage area (218). Subsequently once data is received the function call can then be performed (220-222).) This process is performed in detail in the following manner:
As shown in FIG. 3, the file descriptor is then used to locate the system control table where the program name and 8 byte token that had been saved previously as well as the socket descriptor associated with this TCP/IP socket (338). The system copies the socket descriptor, 8 byte token, the address of the storage block, and the length of the data obtained from an internal header, to another control block associated with a new process that is to be created by the system.
If the file descriptor indicates that the message is received from a datagram socket, the system copies the source address of the message from the internal header to the block associated with the new process. The system then creates the new process (339) and enters the program whose name was obtained from the file descriptor.
CA 02237742 1998-0~-14 To obtain the data7 the new program issues a standard read(), recv(), or recvfrom() socket API function call using the data passed to it by the system in the process. This function call is not sent to the TCP/IP or other similar protocol's stack because the system knows the system already has the data from the network. The purpose of this second read(), recv() or recvfrom() function call is to enable the program to obtain the data from its own buffer or from the buffer obtained by the operating system. After the application has issued the read(), recv() or recvfrom() function call, the system returns the data to the application in the buffer specified by the application.
In a preferred embodiment of the present invention, when the data is larger than the 4K of allocated space, after the first bytes of data are received in the allocated space, in order to obtain the data a read(), recv() or recvfrom() command is issued shown at (345), which allocates the maximum length or other appropriately lengthy space for the transfer and/or copying of the incoming data. However, if the incoming data is to be contained in the 4K of space originally allocated, another activate on receipt() command is issued instead of the read(), recv() or recvfrom() command of the previous case, shown at (350). This second activate_on_receipt function call allows the processing of the data by the system in the allocated 4K of memory without the need to further allocate more memory spaces. In other words, no maximum length space is then allocated to accommodate the copying of a longer data byte.
While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.
Claims (67)
1. In a multi-host computer environment using communication protocols for communicating between said hosts, a method of providing an activate_on_receipt mechanism for handling data transfer requests without causing processing idle time, said method comprising the steps of:
issuing an activate on receipt function call upon receipt of a requested command from one of said processors that requires future receipt and processing of incoming requested data;
allocating a small temporary storage location for receipt of at least a portion of said requested data;
providing parameters such that said incoming requested data can be later returned to said requesting processor, running application and its appropriate communication session;
freeing up system resources and allowing said computer environment to process other operations proceed with processing other operations, until first bytes of said requested data is received at said temporary storage;
upon receipt of first bytes of said incoming requested data, creating a new process to handle immediate processing of said incoming requested data;
processing said incoming requested data directly from said allocated temporary storage when said requested data's size does not exceed size of said allocated temporary storage; and allocating a new storage when said requested data's size exceed size of said temporary allocated storage then copying said requested data from said temporary storage location to said new storage location and receiving any remaining incoming portion of said requested data before processing said requested data.
issuing an activate on receipt function call upon receipt of a requested command from one of said processors that requires future receipt and processing of incoming requested data;
allocating a small temporary storage location for receipt of at least a portion of said requested data;
providing parameters such that said incoming requested data can be later returned to said requesting processor, running application and its appropriate communication session;
freeing up system resources and allowing said computer environment to process other operations proceed with processing other operations, until first bytes of said requested data is received at said temporary storage;
upon receipt of first bytes of said incoming requested data, creating a new process to handle immediate processing of said incoming requested data;
processing said incoming requested data directly from said allocated temporary storage when said requested data's size does not exceed size of said allocated temporary storage; and allocating a new storage when said requested data's size exceed size of said temporary allocated storage then copying said requested data from said temporary storage location to said new storage location and receiving any remaining incoming portion of said requested data before processing said requested data.
2. The method of claim 1, wherein said system environment is allowed to proceed with processing other pending operations and said operations are terminated only when said first bytes arrive in said temporary allocated storage.
3. The method of claim 1, wherein all pending operations are terminated to free up system resources after said activate_on_receipt call has been issued and said system environment is then allowed to create and commence other processed; and any running process is terminated upon the receipt of said first bytes in said temporary allocated storage in favor of creating a new operation that will process said bytes.
4. The method of claim 1, 2 or 3, wherein said temporary allocated storage is 4K in size.
5. The method of any one of claims 1 to 4, wherein said requesting said data is a socket application and said computer environment uses TCP/IP communication protocol.
6. The method of any one of claims 1 to 5, wherein said command mechanism issuesa read command after said first bytes of data is received in said temporary storage location allocated.
7. The method of any one of claims 1 to 6, wherein said requested command is a function call.
8. The method of any one of claims 1 to 4, wherein said requested command is a recvfrom() function call.
9. The method of claim 8, wherein said activate_on_receipt command is issued for a datagram or connectionless socket application such as a UDP socket, and said method further comprises the step of issuing a recvfrom() function call upon receipt of said first bytes of said requested data.
10. The method of any one of claims 1 to 9, wherein said parameters passed include a socket descriptor parameter, a program name pointer and a token pointer.
11. A program storage device readable by a machine, tangibly embodying a programof instructions executable by the machine to perform the method steps of any one of claims 1 to 10.
12. In a multi-host computer environment using communication protocols for communicating between said hosts, an apparatus for handling data transfer requests without causing processing idle time, said apparatus comprising:
an activate_on_receipt mechanism for issuing an activate_on_receipt command when one of said processors issues a command that requires said system environment to suspend processing until said requested data is received;
a small temporary storage allocated for receipt of at least a portion of said requested data;
a plurality of parameters provided and stored at a memory location for later tracing of requesting processor, its running applications and its related communication session information;
a notification mechanism for reporting arrival and receipt of first bytes of requested data in said temporary storage location;
said activate_on_receipt mechanism having means for terminating any running operations on said system environment and creating a new process for processing said requested data upon receipt of notification that said data is being received; and means for determining if said incoming data is larger in size than said space allocated by said temporary location.
an activate_on_receipt mechanism for issuing an activate_on_receipt command when one of said processors issues a command that requires said system environment to suspend processing until said requested data is received;
a small temporary storage allocated for receipt of at least a portion of said requested data;
a plurality of parameters provided and stored at a memory location for later tracing of requesting processor, its running applications and its related communication session information;
a notification mechanism for reporting arrival and receipt of first bytes of requested data in said temporary storage location;
said activate_on_receipt mechanism having means for terminating any running operations on said system environment and creating a new process for processing said requested data upon receipt of notification that said data is being received; and means for determining if said incoming data is larger in size than said space allocated by said temporary location.
13. The apparatus of claim 12, wherein said system environment is allowed to proceed with processing other pending operations and said operations are terminated only when said first bytes arrive in said temporary allocated storage.
14. The apparatus of claim 12, wherein all pending operations are terminated to free up system resources after said activate_on_receipt call has been issued and said system environment is then allowed to create and commence other processed; and any running process is terminated upon the receipt of said first bytes in said temporary allocated storage in favor of creating a new operation that will process said bytes.
15. The apparatus of claim 12, 13 or 14, wherein said temporary allocated storage is 4K in size.
16. The apparatus of any one of claims 12 to 15, wherein said application requesting said data is a socket application and said computer environment uses TCP/IP communication protocol.
17. The apparatus of any one of claims 12 to 16, wherein said activate_on_receipt command mechanism issues a read command after said first bytes of data is received in said temporary storage allocated.
18. The apparatus of any one of claims 12 to 17, wherein said processor issued command is a read function call.
19. The apparatus of any one of claims 12 to 18, wherein said activate on receipt command mechanism copies any incoming data to a new storage data when said size of said incoming data exceeds said size of allocated temporary storage.
20. The apparatus of any one of claims 12 to 15, wherein said activate_on_receipt command is issued for a datagram or connectionless socket.
21. The apparatus of claim 20, wherein said processor issued command is a receive function call.
22. The apparatus of claim 20, wherein said processor issued command is a recvfrom() function call.
23. The apparatus of claim 22, wherein said mechanism issues a recvfrom function call upon receipt of arrival of first bytes of data.
24. The apparatus of any one of claims 20 to 23, wherein said communication protocol is a UDP protocol.
25. The apparatus of any one of claims 12 to 24, wherein said parameters passed include a socket descriptor parameter, a program name pointer and a token pointer.
26. In a computer system having at least one residence operating system, a data processing method comprising the steps of:
issuing a special interface function call upon receipt of a read command;
allowing said computer system process other operations until data pertaining to said read command is received at a temporary storage location set aside for incoming data;
said operating system saving program name and token associated with any application or processor issuing said read command;
creating a socket descriptor to identify any data communication protocols;
creating a system control table entry having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested read command, locating said system control table and tracing said read requesting application or processor by identifying information about where said socket descriptor information resides;
creating a new process in said computer system and entering name of said programrequesting said data as obtained from said system control table; and processing said read command.
issuing a special interface function call upon receipt of a read command;
allowing said computer system process other operations until data pertaining to said read command is received at a temporary storage location set aside for incoming data;
said operating system saving program name and token associated with any application or processor issuing said read command;
creating a socket descriptor to identify any data communication protocols;
creating a system control table entry having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested read command, locating said system control table and tracing said read requesting application or processor by identifying information about where said socket descriptor information resides;
creating a new process in said computer system and entering name of said programrequesting said data as obtained from said system control table; and processing said read command.
27. The method of claim 26, wherein said method further comprises the step of issuing another read command to enable said computer system to obtain data from its own buffer or from any other buffer obtained by its residing operating system.
28. The method of claim 26 or 277 wherein said method further comprises the step of issuing another special program interface function call when said temporary storage location is smaller in size than said incoming data before said data is processed.
29. The method of claim 28, wherein a new storage location is allocated for saidincoming data and said data is copied to said new storage location.
30. The method of any one of claims 26 to 29, wherein TCP/IP communication protocol is used.
31. The method of any one of claims 26 to 30, wherein said program name is identified by a parameter called a program name pointer which points to said program name.
32. The method of any one of claims 26 to 31, wherein said token name is identified by a parameter called a token name pointer which points to said program name.
33. The method of claim 31, wherein said program name pointer comprises address of said program name and is used when said data arrives and is received from another point while performing a data communication session.
34. The method of claim 32, wherein said token name pointer comprises an address of an 8 byte token having data that said application is passing between said processes.
35. The method of claim 32 or 34, wherein said token name parameter is 8 bytes in length.
36. The method of any one of claims 26 to 35, wherein said socket descriptor is a parameter associated with said running application's communication session.
37. The method of any one of claims 26 to 36, wherein said socket descriptor is an integer.
38. A program storage device readable by a machine, tangibly embodying a programof instructions executable by the machine to perform the method steps of any one of claims 26 to 37.
39. In a computer system having at least one residence operating system, a data processing method comprising the steps of:
issuing an activate_on_receipt application program interface function call and terminate the process;
allowing said computer system process other operations until data pertaining to said receive command is received;
said operating system saving program name and token associated with any application issuing said activate_on_receipt command;
creating a socket descriptor to identify any data communication protocols;
creating a system control table having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested receive command, locating said system control table and finding said socket descriptor information resides;
creating a new process in said computer system and entering name of said programrequesting said data as obtained from said system control table; and processing said read command.
issuing an activate_on_receipt application program interface function call and terminate the process;
allowing said computer system process other operations until data pertaining to said receive command is received;
said operating system saving program name and token associated with any application issuing said activate_on_receipt command;
creating a socket descriptor to identify any data communication protocols;
creating a system control table having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested receive command, locating said system control table and finding said socket descriptor information resides;
creating a new process in said computer system and entering name of said programrequesting said data as obtained from said system control table; and processing said read command.
40. The method of claim 39, wherein said method further comprises the step of issuing another receive command to enable said computer system to obtain data from its own buffer or from any other buffer obtained by its residing operating system.
41. The method of claim 39 or 40, wherein said method further comprises the step of issuing another special program interface function call when said temporary storage location is smaller in size than said incoming data before said data is processed.
42. The method of claim 41, wherein a new storage location is allocated for saidincoming data and said data is copied to said new storage location.
43. The method of any one of claims 39 to 42, wherein said receive command is issued for a datagram or connectionless socket.
44. The method of any one of claims 39 to 43, wherein said program name is identified by a parameter called a program name pointer which points to said program name.
45. The method of any one of claims 39 to 44, wherein said token name is identified by a parameter called a token name pointer which points to said program name.
46. The method of claim 44, wherein said program name pointer comprises address of said program name and is used when said data arrives and is received from another point while performing a data communication session.
47. The method of claim 45, wherein said token name pointer comprises an address of an 8 byte token having data that said application is passing between said processes.
48. The method of claims 45 or 47, wherein said token name parameter is 8 bytes in length.
49. The method of any one of claims 39 to 48, wherein said socket descriptor is a parameter associated with said running application's communication session.
50. The method of any one of claims 39 to 497 wherein said socket descriptor is an
51. The method of any one of claims 39 to 50, wherein said receive command is a recvfrom() function call.
52. A program storage device readable by a machine, tangibly embodying a programof instructions executable by the machine to perform the method steps of any one of claims 39 to 51.
53. In a computer system having at least one residence operating system, a data processing apparatus comprising:
means for issuing an activate_on_receipt application program interface function call upon receipt of a read command;
means for saving program name and token associated with any application issuing said read command;
a mechanism for creating a socket descriptor to identify any data communication protocols;
a system control table having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested read command, means for locating said system control table and finding said socket descriptor information resides;
means for creating a new process in said computer system and entering name of said program requesting said data as obtained from said system control table; and means for processing said read command.
means for issuing an activate_on_receipt application program interface function call upon receipt of a read command;
means for saving program name and token associated with any application issuing said read command;
a mechanism for creating a socket descriptor to identify any data communication protocols;
a system control table having a file descriptor for saving said program name and token information in a data structure format and associating them with said socket descriptor;
upon receipt of data pertaining to said requested read command, means for locating said system control table and finding said socket descriptor information resides;
means for creating a new process in said computer system and entering name of said program requesting said data as obtained from said system control table; and means for processing said read command.
54. The apparatus of claim 53 further comprising, means for issuing another readcommand to enable said computer system to obtain data from its own buffer or from any other buffer obtained by its residing operating system.
55. The apparatus of claim 53 or 54, further comprising, means for issuing another special program interface function call when said temporary storage location is smaller in size than said incoming data before said data is processed.
56. The apparatus of claim 55, wherein a new storage location is allocated for said incoming data and said data is copied to said new storage location.
57. The apparatus of any one of claims 53 to 56, wherein TCP/IP communication protocol is used.
58. The apparatus of any one of claims 53 to 57, wherein said program name is identified by a parameter called a program name pointer which points to said program name.
59. The apparatus of any one of claims 53 to 58, wherein said token name is identified by a parameter called a token name pointer which points to said program name.
60. The apparatus of claim 58, wherein said program name pointer comprises address of said program name and is used when said data arrives and is received from another point while performing a data communication session.
61. The apparatus of claim 59, wherein said token name pointer comprises an address of an 8 byte token having data that said application is passing between said processes.
62. The apparatus of claims 59 or 61, wherein said token name parameter is 8 bytes in length.
63. The apparatus of any one of claims 53 to 62, wherein said socket descriptor is a parameter associated with said running application's communication session.
64. The apparatus of any one of claims 53 to 63, wherein said socket descriptor is an integer.
65. The apparatus of any one of claims 53 to 56, wherein said read command is a receive command.
66. The apparatus of claim 65, wherein said activate_on_receipt command is issued for a datagram or connectionless socket.
67. The apparatus of claim 65 or 66, wherein receive command is a recvfrom() command.
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US86558097A | 1997-05-29 | 1997-05-29 | |
| US86516697A | 1997-05-29 | 1997-05-29 | |
| US86481497A | 1997-05-29 | 1997-05-29 | |
| US86480897A | 1997-05-29 | 1997-05-29 | |
| US08/864,814 | 1997-05-29 | ||
| US08/864,808 | 1997-05-29 | ||
| US08/865,166 | 1997-05-29 | ||
| US08/865,580 | 1997-05-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2237742A1 true CA2237742A1 (en) | 1998-11-29 |
Family
ID=27505943
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2237742 Abandoned CA2237742A1 (en) | 1997-05-29 | 1998-05-14 | A system resource reduction tool utilizing tcp/ip socket applications |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2237742A1 (en) |
-
1998
- 1998-05-14 CA CA 2237742 patent/CA2237742A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5530905A (en) | Temporary state preservation for a distributed file service which purges virtual circuit control information after expiration of time limit of inactivity | |
| US5727142A (en) | Method for a non-disruptive host connection switch after detection of an error condition or during a host outage or failure | |
| US7246167B2 (en) | Communication multiplexor using listener process to detect newly active client connections and passes to dispatcher processes for handling the connections | |
| EP0794491B1 (en) | Client/server architecture supporting concurrent servers | |
| US6247056B1 (en) | Method and apparatus for handling client request with a distributed web application server | |
| JP3364587B2 (en) | System and method for controlling transmission of relatively large data objects in a communication system | |
| KR100373381B1 (en) | Method and system for memory management in a network processing system | |
| JP3382953B2 (en) | Client management flow control method and apparatus on finite memory computer system | |
| KR100326864B1 (en) | Network communication method and network system | |
| US6192389B1 (en) | Method and apparatus for transferring file descriptors in a multiprocess, multithreaded client/server system | |
| EP0362107B1 (en) | Method to manage concurrent execution of a distributed application program by a host computer and a large plurality of intelligent work stations on an SNA network | |
| US6081846A (en) | Method and computer program product for reducing intra-system data copying during network packet processing | |
| US8239588B2 (en) | System and method for improved I/O node control in computer system | |
| EP2240852B1 (en) | Scalable sockets | |
| EP0381645A2 (en) | System and method for communicating between a plurality of processors | |
| JPH10124470A (en) | Mechanism for calling processing of multiplexed message with small overhead of low context switching | |
| US5535334A (en) | Fault-tolerant system-to-system communications system and method utilizing multiple communications methods to transfer a single message | |
| US9069592B2 (en) | Generic transport layer mechanism for firmware communication | |
| CA2237742A1 (en) | A system resource reduction tool utilizing tcp/ip socket applications | |
| KR19980086588A (en) | System Resource Reduction Tool Using TCP / IP Socket Application | |
| US5392426A (en) | Method and apparatus for use in program operation, control and control block management and storage | |
| KR19980086586A (en) | System Resource Reduction Tool Using TCP / IP Socket Application | |
| KR19980086589A (en) | System Resource Reduction Tool Using TCP / IP Socket Application | |
| KR19980086587A (en) | System Resource Reduction Tool Using TCP / IP Socket Application | |
| KR20230085075A (en) | Apparatus and method for accelerating network transmission in memory disaggregation environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |