CA2107299C - High performance machine for switched communications in a heterogenous data processing network gateway - Google Patents
High performance machine for switched communications in a heterogenous data processing network gatewayInfo
- Publication number
- CA2107299C CA2107299C CA002107299A CA2107299A CA2107299C CA 2107299 C CA2107299 C CA 2107299C CA 002107299 A CA002107299 A CA 002107299A CA 2107299 A CA2107299 A CA 2107299A CA 2107299 C CA2107299 C CA 2107299C
- Authority
- CA
- Canada
- Prior art keywords
- gateway
- switched
- calls
- remote procedure
- network
- 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.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Abstract
In a distributed system , such as a local area network having a facility for synchronous remote procedure calls and multi-threading, an interface mechanism for linking client workstations on the distributed system with external switched communications networks is provided. The interface extends the remote procedure calling facility beyond the distributed system by classifying the different types of remote procedure calls that can be issued to a switched communications gateway in the distributed system, and permitting the issuance of multiple threads of control, according to the type of function the procedure call represents. Related functions are forced to execute sequentially at the gateway, while those classified as unrelated functions can execute sequentially. The advantages of heterogeneity and concurrency of the distributed system are thus extended to its switched communications links with external switched networks.
Description
CA9-93-014 1 21 0 72 ~ 3 HIG~ PERFORMANCE MACHINF, FOR SWITC~ COMMUNICATIONS
IN A HETEROGENEOUS DATA PROCESSING NETWORK GATEWAY
Field of the Invention The present invention provides an interface mechanism in a communications gateway for linking users in a heterogeneous distributed system, such as a local area network (LAN), to remote services over a circuit-switched communications network. It also enables users, remotely located across one or more circuit switched networks, to access services offered by one or more machines situated on one or more heterogeneous local networks.
Background of the Invention A distributed system i5, broadly speaking, an aggregate of individual systems that are connected via electronic communications. The separation of components inherent in a distributed system provides advantages over a tightly integrated system approach iIl allowing the truly parallel execution of programs, the containment of faults without system disruption, and the use of isolation and interlocks as security enforcement measures.
A LAN is a type of distrikiuted system that loosely couples remote processors and workstations. Generally, workstations on a LAN do not share a central memory, but do share common servers such as one or mol-e file servers, print servers, etc. High-speed LANs, in particular, effectively increase the power and flexibility of workstations (computers designed for one or more single users with sufficient processing power and memory to run users' application programs) by enabling them to have access to shared data and resources located in their own and other server computers.
The LAN system that has been in the widest use in recent years is produced by Novel], Inc. of Provo, Utah. In a Novell system, a LAN devic-e driver is implemented on top of CA9-93-014 2 210 7 ~ ~ 9 the local operating systems to be coupled, and device driver commands (and responses) at the LAN workstations are directed from (and to) the workstations onto the LAN to (and from) the target servers.
As the users of personal computers and workstations, as well as minicomputers, mainframes and supercomputers, try to take better advantage of their combined resources, LANs are being grown with disparate (i.e., heterogeneous) systems made up of the variety of hardware, software and applications already installed.
However, network access and connectivity alone are not sufficient to perform useful work between disparate systems on a LAN. These components must have a common understanding of the particular type of work or application to interoperate. They must also utilise the same procedures to implement that type of work. One level of interoperability is to establish terminal emulation to access applications on other systems. Another option is to use a batch file transfer mechanism to transfer data to another machine, where a program wil] parse the data and perform work on it according to a pre-established protocol. Both of these mechanisms require system specific software that is not portable without modification, for connecting other types of hardware and/or operating systems.
One goal of developments iIl distributed systems is to develop means for providing interoperability that is more universal (portable to a larger number of computers and/or operating system types), while maintaining transparency (concealment of separation) to the user (whether that user is a machine or application). Ideally, the user should not be aware of accessing resources on remote servers in a LAN, but should perceive the system as a whole rather than as a collection of individual components.
In a homogeneous distributed system, such as the Novell Netwarel LAN, each separate computer has the same operating system and identical software hierarchy. In the Novell system, this is the Netware Asynchronous Service Interface (NASI). The LAN device driver contains facilities for communications between processes in separate computers.
Again, in the Novell system, this is the Netware Asynchronous Communications Server (NACS).
The Distributed Computing Environment (DCE) of the Open System Foundation (OSF2) is a very recent emerging technology enabling distributed computing among heterogeneous systems. When implemented on each of the disparate systems, DCE allows transparent interoperation between computers on the LAN through a mechanism called the remote procedure call (RPC) that extends to the distributed environment the concept of a local procedure call, a well understood communications mechanism for constructing a program using subroutines (also called subprograms or procedures) within an operating system. The RPC mechanism is implemented in DCE in conjunction with a multi-threading capability similar to that described in the IEEE POSIX
1003.4a draft standard . This combination permits RPC
concurrency in the OSF DCE environment.
Normally, in the absence of an RPC mechanism, there is a unique interface between the calling program and a specific subroutine, and the local procedure call invokes all necessary logic for operability. When the subroutine resides on a different machine than the calling program, communications logic (i.e., the location of the subroutine, Trademark of Novell, Inc.
Trademarks of the Open Software Foundation IEEE P1003.4a/D4 draft standard, Threads Extension for Portable Operating Systems, Technical Committee on Operating Systems of the Institute of Electrical and Electronic Engineers (IEEE) Computer Society, New York, NY, USA, August 10, 1990.
CA9-93-014 4 21072~9 data conversions, etc.) is required for the call and must be hard-coded into the calling and/or called programs.
In OSF's DCE, the RPC itself automatically invokes the communications services for the programmer, and all, or optionally almost all, communications code, error handling and data conversion are handled transparently, thereby removing concern for the communications mechanisms from the programs that use remote procedures.
In the DCE system, for each subroutine call, the RPC
mechanism can automatically invoke a directory that provides naming and other support protocols for every resource in the network. Thus, application programs can make use of distributed services by issuing calls to remote procedures by name, without knowing their location(s). This provides location transparency, as the distributed system is completely configurable in terms of the location of its components. As described above, the RPC mechanism also permits heterogeneity in the DCE environment.
The increasing proliferation of remote electronic information exchange has made access to remote servers such as processors and databases a necessity. This access is often facilitated through circuit-switched communications links over wide area networks (WANs).
A useful description of a typical switched area network of this type is that found iIl U. S. Patent Nos. 4,896,319, 4,897,874 and 4,958,341, all to A T & T, that relate to a "metropolitan area network" (MAN). The switches described in these patents are similar to those typically used for WANs, although the protocols for the type of system specified appears to be directed to the secure transmission of data.
Typically, access to or from a remote machine across a WAN
from (or to) a workstation on a LAN is gained by instituting a switched communications link through a LAN gateway server.
A device driver for the gateway is provided with physical CA9-93-014 5 2 1 0 7 ~ 9 9 ports (or modems) tha1 can be linked to switched communications WANs.
Existing gateway mechanisms, such as Novell's NACS and NASI, are generally implemented on top of the LAN device driver as a switched communications device interface and a LAN
redirection facility on the workstation programming interface, and a corresponding LAN redirection facility and switched communications device interface implemented at the gateway, providing for both -the transmission and receipt of switched communications links through the gateway modems.
Redirections are also used for communicating serial port and modem commands between the gateway and other machines on the LAN.
In such systems, the user's initialization of the communications link-up procedure redirects the user hardware commands to the gateway. The communications interface in the gateway driver then institutes and maintains the switched communications link, diverting hardware resources of the driver to do so. An exclusive device driver access mode would typically be used in accessing the remote ports.
The connection and access procedures are then executed using the gateway ports and modems in order to link the user's system with the switched communications network. A remote connection is established through the WAN. This sets up a point-to-point configuration through the port along the communication line between the user computer and server computer, monopolizing the switched communications device in use.
The device driver interface is hardware-oriented, and imposes the restriction that the device drivers in the workstations and LANs support compatible LAN redirection facilities. These are generally not available in a heterogeneous system, with the result that most current LAN
systems require that the computer and/or operating system at the workstations and the gateway be homogeneous.
Also, the LAN workstations are effectively in full control of the switched hardware ports at the gateway. This virtually eliminates the possibility of implementing any flexible automatic and transparent support for regulated network attachments in the centralized gateway.
One area impacted is the regulation and certification required for attachment to particular WANs or switched networks. Examples of such regulation include various software timeout and frequency limit requirements for call activities, as well as hardware management schemes.
Presently, the workstation software applications should be separately updated according to the periodically-issued CCITT recommendations and separately certified.
In addition, the workstation software applications must be aware of the types of modems attached to the gateway WAN
ports, and should replicate specific software support to take advantage of distinct features for these various devices. Because these protocols cannot be implemented at the central gateway, manual configuration steps in the attachment process across all of the workstations are often required.
In order to emulate heterogeneity in systems without RPCs, translation mechanisms are also required to support incompatible data representations (e.g., big and little endian formats) and character sets (e.g., ASCII and various EBCDIC code pages) between the LAN workstations, the gateway and/or the modems. For example, character set support in the Novell-based LAN gateway mechanism is restricted to ASCII, and the word widths of the device driver interfaces are fixed.
While the current approach of redirecting the LAN device driver facilitates relatively fast single-message transfers across the LAN, this direct access also results in monopolization of these driver resources for effecting and maintaining a switched communications link for certain users while denying access to others.
SUMMARY OF THE INVENTION
It is an object of the present invention to utilise the emerging RPC technology to effect switched communications links between LANs and WANs, and particularly, to extend heterogeneity across a LAN environment utilising RPCs, to a switched gateway. It is therefore an object of this invention to provide an interface mechanism for a LAN
gateway operable in a heterogeneous distributed environment.
It is also an object of the present invention to provide concurrency for managing switched communications from a heterogeneous network.
It is a further object of this invention to implement a gateway machine that would be useful in transparently and centrally enforcing regulation support for the LAN
workstations for accessing WANs and switched networks - by isolating the LAN workstations from direct access to the gateway ports.
Accordingly, the present invention provides an interface mechanism for a switched communications gateway in a distributed computing network having means for issuing remote procedure calls across the distributed network, means for concurrently processing multiple remote procedures calls between at least one computer and the gateway across the distributed system, and scheduling means for sequentially processing remote procedure calls for related functions at the gateway.
Preferably, the scheduling means includes means for classifying remote procedure calls into related functions.
BRIEF DESCRIPTION OF THE ~RAWINGS
Figure 1 is a schematic representation of a LAN network supporting a homogeneous computing environment of the prior art.
Figure 2 is a schematic overview diagram illustrating the functional layers in an interface for implementing concurrent RPCs in a LAN.
Figure 3 is a schematic depiction of the target heterogeneous distributed environment and a switched communications network for the high performance communications interface machine of the present invention.
Figure 4 is a block diagram of a gateway server implemented through remote procedure calls (RPCs) as a high performance machine, according to the invention.
Figures 5 and 6 are flow diagrams illustrating the procedures used for emulating outgoing and incoming switched calls in an experimental set-up of a high performance machine for a LAN gateway, according to the invention.
DETAILED DESCRIPTION OF l~ PREFERRED EMBODIMENTS
Figure 1 illustrates a LAN, generally designated by 1, for a homogeneous computing environment, of the type of the Novell implementation described above.
A client machine 2 on the LAN 1 seeks to issue an outgoing call through the LAN gateway server 4 to a remote server 13 across a switched network 12, while another client machine 3 (also called a server to remote users 14 across the switched network 12) entertains an incoming call received through the gateway server 4. (It should be recognised that a "client machine" is a client to the gateway running at least one application process, and may be attended or unattended by a human agent.) For simplicity, the following common coding has been used in Figures 1 and 3 to differentiate the active states of individual workstations and processors in both LANs and WANs: workstations/processors shown as shaded squares are intended to denote client machines issuing outgoing calls, while those depicted as unshaded circles are intended to denote server machines receiving incoming calls.
The client machine 2 with the outgoing call issues a command through its programming interface 5 with the LAN 1 to implement a switched communications interface 6, that in turn connects to a LAN redirection facility 7 for redirecting the device driver commands over the LAN 1 to the parallel corresponding interface mechanisms 8 and 9 at the LAN gateway 4.
The gateway 4 contains a number (m) of switched communications ports 11 that can be linked to the switched communications network 12.
As the command for issuing an outgoing call from the user 2 is received from the LAN 1, the LAN redirection facility 8 and switched communications device interface 9 on the gateway 4 side of the LAN 1 include logic that channels the call command to the taryet port from the appropriate pool of ports.
An incoming call to the gateway 4 passes, in parallel fashion, through the switched communications device interface 9 and LAN redirection facility 8 on the gateway 4 side of the LAN 1 before crossing the LAN and passing through the communications interface layers 7 and 6 that complete the connection requested by the server machine 3.
Users 2 and 3 can be applications in the same (client) machine or different (client) machines.
In the NACS and NASI implementations of Novell, in the absence of a conversion interface written to the specific application (i.e., accessing a switched communications gateway), the user (2, 3) side and the gateway 4 side of the LAN must utilise a common operating system environment, that is, the LAN must be homogeneous.
CA9-93-014 2 1 0 72 ~ 9 lo In its DCE, OSF has addressed the homogeneity problem in LANs through the use of RPCs.
A schematic overview of the mechanism for implementing RPCs in a LAN, such as OSF's DCE, is shown in Figure 2. The underlying network is transparent to the client and server programs. Although reference is generally made herein to LANs since this is the predominant implementation, it should be noted that the present invention could also be implemented on a WAN.
Connectivity and interoperability between user workstations and servers that may be heterogeneous (i.e., utilising different computer hardware and/or operating system environments) are achieved using RPC interfaces to implement transparent communicatiolls across the heterogeneous distributed system, with the result that the RPCs appear to the client machine to be transparent local procedure calls.
In Figure 2, a client workstation application thread 21 and server application thread 22 on opposite sides of a LAN 20 are shown, with the RPC interfaces 23 and 24 interleaved, in symmetrical fashion, between the client thread 21 and the network routines 25 for accessing the LAN hardware (device driver) on one side, and between the server 22 and network routines 26 on the other side. The client thread 21 and its RPC interfaces 23 and network routines 25 are generally implemented in one system, as are the server thread 22 and its RPC interfaces 24 and network routines 26. Through the transparency provided by RPCs, these systems may be disparate (i.e., separate and heterogeneous) or may reside on the same machine and perform in the same way.
The RPC issued from the client thread 21 to the server 22 is sent in the form of a request message (whether this is a remote processor or a server residing on the same machine as the sender), and the server is ahle to transparently receive the call, execute the procedure and return a reply message.
Analogous to local procedure calls, the calling program in the user 21 waits until the called procedure returns.
Because remote procedures cannot have access to any variable or data values in the calling program's environment (since the procedure is executed in a disjoint address space), an interface compiler (not shown) is generally used as a basis for integration of RPCs into the respective operating system languages of the user 21 and server 22. The interface compiler replaces each call to a remote procedure in the client program by a call to a client stub procedure 23.
This is the procedure in the client program that "stands-in"
for the remote procedure in the server program. The task of the client stub 23 is to marshal the arguments and pack them up with the procedure identifier into a message, send the message to the server, and then await the reply message, (un)marshal it and return the results.
Before the server program is compiled, it too is pre-processed by the interface compiler that checks the procedure definitions in the server against the interface specification, and generates a server stub 26 that obtains input arguments by (un)marshalling the request message, calling the appropriate server procedure, and when it returns, marshalling the output arguments (or in the case of a failure, an error report) and making a reply message which it sends back to the client.
Through the concurrency provided by multi-threading, several RPC procedures can be occurring simllltaneously, in parallel, in the network. This is illustrated schematically in Figure 2 with multiple instances of each schematic block.
In OSF's DCE, the RPC interfaces support (among other things):
1. network and transport protocols that may be connectionless or connection-oriented;
2. similar and dissimilar hardware and/or operating systems;
IN A HETEROGENEOUS DATA PROCESSING NETWORK GATEWAY
Field of the Invention The present invention provides an interface mechanism in a communications gateway for linking users in a heterogeneous distributed system, such as a local area network (LAN), to remote services over a circuit-switched communications network. It also enables users, remotely located across one or more circuit switched networks, to access services offered by one or more machines situated on one or more heterogeneous local networks.
Background of the Invention A distributed system i5, broadly speaking, an aggregate of individual systems that are connected via electronic communications. The separation of components inherent in a distributed system provides advantages over a tightly integrated system approach iIl allowing the truly parallel execution of programs, the containment of faults without system disruption, and the use of isolation and interlocks as security enforcement measures.
A LAN is a type of distrikiuted system that loosely couples remote processors and workstations. Generally, workstations on a LAN do not share a central memory, but do share common servers such as one or mol-e file servers, print servers, etc. High-speed LANs, in particular, effectively increase the power and flexibility of workstations (computers designed for one or more single users with sufficient processing power and memory to run users' application programs) by enabling them to have access to shared data and resources located in their own and other server computers.
The LAN system that has been in the widest use in recent years is produced by Novel], Inc. of Provo, Utah. In a Novell system, a LAN devic-e driver is implemented on top of CA9-93-014 2 210 7 ~ ~ 9 the local operating systems to be coupled, and device driver commands (and responses) at the LAN workstations are directed from (and to) the workstations onto the LAN to (and from) the target servers.
As the users of personal computers and workstations, as well as minicomputers, mainframes and supercomputers, try to take better advantage of their combined resources, LANs are being grown with disparate (i.e., heterogeneous) systems made up of the variety of hardware, software and applications already installed.
However, network access and connectivity alone are not sufficient to perform useful work between disparate systems on a LAN. These components must have a common understanding of the particular type of work or application to interoperate. They must also utilise the same procedures to implement that type of work. One level of interoperability is to establish terminal emulation to access applications on other systems. Another option is to use a batch file transfer mechanism to transfer data to another machine, where a program wil] parse the data and perform work on it according to a pre-established protocol. Both of these mechanisms require system specific software that is not portable without modification, for connecting other types of hardware and/or operating systems.
One goal of developments iIl distributed systems is to develop means for providing interoperability that is more universal (portable to a larger number of computers and/or operating system types), while maintaining transparency (concealment of separation) to the user (whether that user is a machine or application). Ideally, the user should not be aware of accessing resources on remote servers in a LAN, but should perceive the system as a whole rather than as a collection of individual components.
In a homogeneous distributed system, such as the Novell Netwarel LAN, each separate computer has the same operating system and identical software hierarchy. In the Novell system, this is the Netware Asynchronous Service Interface (NASI). The LAN device driver contains facilities for communications between processes in separate computers.
Again, in the Novell system, this is the Netware Asynchronous Communications Server (NACS).
The Distributed Computing Environment (DCE) of the Open System Foundation (OSF2) is a very recent emerging technology enabling distributed computing among heterogeneous systems. When implemented on each of the disparate systems, DCE allows transparent interoperation between computers on the LAN through a mechanism called the remote procedure call (RPC) that extends to the distributed environment the concept of a local procedure call, a well understood communications mechanism for constructing a program using subroutines (also called subprograms or procedures) within an operating system. The RPC mechanism is implemented in DCE in conjunction with a multi-threading capability similar to that described in the IEEE POSIX
1003.4a draft standard . This combination permits RPC
concurrency in the OSF DCE environment.
Normally, in the absence of an RPC mechanism, there is a unique interface between the calling program and a specific subroutine, and the local procedure call invokes all necessary logic for operability. When the subroutine resides on a different machine than the calling program, communications logic (i.e., the location of the subroutine, Trademark of Novell, Inc.
Trademarks of the Open Software Foundation IEEE P1003.4a/D4 draft standard, Threads Extension for Portable Operating Systems, Technical Committee on Operating Systems of the Institute of Electrical and Electronic Engineers (IEEE) Computer Society, New York, NY, USA, August 10, 1990.
CA9-93-014 4 21072~9 data conversions, etc.) is required for the call and must be hard-coded into the calling and/or called programs.
In OSF's DCE, the RPC itself automatically invokes the communications services for the programmer, and all, or optionally almost all, communications code, error handling and data conversion are handled transparently, thereby removing concern for the communications mechanisms from the programs that use remote procedures.
In the DCE system, for each subroutine call, the RPC
mechanism can automatically invoke a directory that provides naming and other support protocols for every resource in the network. Thus, application programs can make use of distributed services by issuing calls to remote procedures by name, without knowing their location(s). This provides location transparency, as the distributed system is completely configurable in terms of the location of its components. As described above, the RPC mechanism also permits heterogeneity in the DCE environment.
The increasing proliferation of remote electronic information exchange has made access to remote servers such as processors and databases a necessity. This access is often facilitated through circuit-switched communications links over wide area networks (WANs).
A useful description of a typical switched area network of this type is that found iIl U. S. Patent Nos. 4,896,319, 4,897,874 and 4,958,341, all to A T & T, that relate to a "metropolitan area network" (MAN). The switches described in these patents are similar to those typically used for WANs, although the protocols for the type of system specified appears to be directed to the secure transmission of data.
Typically, access to or from a remote machine across a WAN
from (or to) a workstation on a LAN is gained by instituting a switched communications link through a LAN gateway server.
A device driver for the gateway is provided with physical CA9-93-014 5 2 1 0 7 ~ 9 9 ports (or modems) tha1 can be linked to switched communications WANs.
Existing gateway mechanisms, such as Novell's NACS and NASI, are generally implemented on top of the LAN device driver as a switched communications device interface and a LAN
redirection facility on the workstation programming interface, and a corresponding LAN redirection facility and switched communications device interface implemented at the gateway, providing for both -the transmission and receipt of switched communications links through the gateway modems.
Redirections are also used for communicating serial port and modem commands between the gateway and other machines on the LAN.
In such systems, the user's initialization of the communications link-up procedure redirects the user hardware commands to the gateway. The communications interface in the gateway driver then institutes and maintains the switched communications link, diverting hardware resources of the driver to do so. An exclusive device driver access mode would typically be used in accessing the remote ports.
The connection and access procedures are then executed using the gateway ports and modems in order to link the user's system with the switched communications network. A remote connection is established through the WAN. This sets up a point-to-point configuration through the port along the communication line between the user computer and server computer, monopolizing the switched communications device in use.
The device driver interface is hardware-oriented, and imposes the restriction that the device drivers in the workstations and LANs support compatible LAN redirection facilities. These are generally not available in a heterogeneous system, with the result that most current LAN
systems require that the computer and/or operating system at the workstations and the gateway be homogeneous.
Also, the LAN workstations are effectively in full control of the switched hardware ports at the gateway. This virtually eliminates the possibility of implementing any flexible automatic and transparent support for regulated network attachments in the centralized gateway.
One area impacted is the regulation and certification required for attachment to particular WANs or switched networks. Examples of such regulation include various software timeout and frequency limit requirements for call activities, as well as hardware management schemes.
Presently, the workstation software applications should be separately updated according to the periodically-issued CCITT recommendations and separately certified.
In addition, the workstation software applications must be aware of the types of modems attached to the gateway WAN
ports, and should replicate specific software support to take advantage of distinct features for these various devices. Because these protocols cannot be implemented at the central gateway, manual configuration steps in the attachment process across all of the workstations are often required.
In order to emulate heterogeneity in systems without RPCs, translation mechanisms are also required to support incompatible data representations (e.g., big and little endian formats) and character sets (e.g., ASCII and various EBCDIC code pages) between the LAN workstations, the gateway and/or the modems. For example, character set support in the Novell-based LAN gateway mechanism is restricted to ASCII, and the word widths of the device driver interfaces are fixed.
While the current approach of redirecting the LAN device driver facilitates relatively fast single-message transfers across the LAN, this direct access also results in monopolization of these driver resources for effecting and maintaining a switched communications link for certain users while denying access to others.
SUMMARY OF THE INVENTION
It is an object of the present invention to utilise the emerging RPC technology to effect switched communications links between LANs and WANs, and particularly, to extend heterogeneity across a LAN environment utilising RPCs, to a switched gateway. It is therefore an object of this invention to provide an interface mechanism for a LAN
gateway operable in a heterogeneous distributed environment.
It is also an object of the present invention to provide concurrency for managing switched communications from a heterogeneous network.
It is a further object of this invention to implement a gateway machine that would be useful in transparently and centrally enforcing regulation support for the LAN
workstations for accessing WANs and switched networks - by isolating the LAN workstations from direct access to the gateway ports.
Accordingly, the present invention provides an interface mechanism for a switched communications gateway in a distributed computing network having means for issuing remote procedure calls across the distributed network, means for concurrently processing multiple remote procedures calls between at least one computer and the gateway across the distributed system, and scheduling means for sequentially processing remote procedure calls for related functions at the gateway.
Preferably, the scheduling means includes means for classifying remote procedure calls into related functions.
BRIEF DESCRIPTION OF THE ~RAWINGS
Figure 1 is a schematic representation of a LAN network supporting a homogeneous computing environment of the prior art.
Figure 2 is a schematic overview diagram illustrating the functional layers in an interface for implementing concurrent RPCs in a LAN.
Figure 3 is a schematic depiction of the target heterogeneous distributed environment and a switched communications network for the high performance communications interface machine of the present invention.
Figure 4 is a block diagram of a gateway server implemented through remote procedure calls (RPCs) as a high performance machine, according to the invention.
Figures 5 and 6 are flow diagrams illustrating the procedures used for emulating outgoing and incoming switched calls in an experimental set-up of a high performance machine for a LAN gateway, according to the invention.
DETAILED DESCRIPTION OF l~ PREFERRED EMBODIMENTS
Figure 1 illustrates a LAN, generally designated by 1, for a homogeneous computing environment, of the type of the Novell implementation described above.
A client machine 2 on the LAN 1 seeks to issue an outgoing call through the LAN gateway server 4 to a remote server 13 across a switched network 12, while another client machine 3 (also called a server to remote users 14 across the switched network 12) entertains an incoming call received through the gateway server 4. (It should be recognised that a "client machine" is a client to the gateway running at least one application process, and may be attended or unattended by a human agent.) For simplicity, the following common coding has been used in Figures 1 and 3 to differentiate the active states of individual workstations and processors in both LANs and WANs: workstations/processors shown as shaded squares are intended to denote client machines issuing outgoing calls, while those depicted as unshaded circles are intended to denote server machines receiving incoming calls.
The client machine 2 with the outgoing call issues a command through its programming interface 5 with the LAN 1 to implement a switched communications interface 6, that in turn connects to a LAN redirection facility 7 for redirecting the device driver commands over the LAN 1 to the parallel corresponding interface mechanisms 8 and 9 at the LAN gateway 4.
The gateway 4 contains a number (m) of switched communications ports 11 that can be linked to the switched communications network 12.
As the command for issuing an outgoing call from the user 2 is received from the LAN 1, the LAN redirection facility 8 and switched communications device interface 9 on the gateway 4 side of the LAN 1 include logic that channels the call command to the taryet port from the appropriate pool of ports.
An incoming call to the gateway 4 passes, in parallel fashion, through the switched communications device interface 9 and LAN redirection facility 8 on the gateway 4 side of the LAN 1 before crossing the LAN and passing through the communications interface layers 7 and 6 that complete the connection requested by the server machine 3.
Users 2 and 3 can be applications in the same (client) machine or different (client) machines.
In the NACS and NASI implementations of Novell, in the absence of a conversion interface written to the specific application (i.e., accessing a switched communications gateway), the user (2, 3) side and the gateway 4 side of the LAN must utilise a common operating system environment, that is, the LAN must be homogeneous.
CA9-93-014 2 1 0 72 ~ 9 lo In its DCE, OSF has addressed the homogeneity problem in LANs through the use of RPCs.
A schematic overview of the mechanism for implementing RPCs in a LAN, such as OSF's DCE, is shown in Figure 2. The underlying network is transparent to the client and server programs. Although reference is generally made herein to LANs since this is the predominant implementation, it should be noted that the present invention could also be implemented on a WAN.
Connectivity and interoperability between user workstations and servers that may be heterogeneous (i.e., utilising different computer hardware and/or operating system environments) are achieved using RPC interfaces to implement transparent communicatiolls across the heterogeneous distributed system, with the result that the RPCs appear to the client machine to be transparent local procedure calls.
In Figure 2, a client workstation application thread 21 and server application thread 22 on opposite sides of a LAN 20 are shown, with the RPC interfaces 23 and 24 interleaved, in symmetrical fashion, between the client thread 21 and the network routines 25 for accessing the LAN hardware (device driver) on one side, and between the server 22 and network routines 26 on the other side. The client thread 21 and its RPC interfaces 23 and network routines 25 are generally implemented in one system, as are the server thread 22 and its RPC interfaces 24 and network routines 26. Through the transparency provided by RPCs, these systems may be disparate (i.e., separate and heterogeneous) or may reside on the same machine and perform in the same way.
The RPC issued from the client thread 21 to the server 22 is sent in the form of a request message (whether this is a remote processor or a server residing on the same machine as the sender), and the server is ahle to transparently receive the call, execute the procedure and return a reply message.
Analogous to local procedure calls, the calling program in the user 21 waits until the called procedure returns.
Because remote procedures cannot have access to any variable or data values in the calling program's environment (since the procedure is executed in a disjoint address space), an interface compiler (not shown) is generally used as a basis for integration of RPCs into the respective operating system languages of the user 21 and server 22. The interface compiler replaces each call to a remote procedure in the client program by a call to a client stub procedure 23.
This is the procedure in the client program that "stands-in"
for the remote procedure in the server program. The task of the client stub 23 is to marshal the arguments and pack them up with the procedure identifier into a message, send the message to the server, and then await the reply message, (un)marshal it and return the results.
Before the server program is compiled, it too is pre-processed by the interface compiler that checks the procedure definitions in the server against the interface specification, and generates a server stub 26 that obtains input arguments by (un)marshalling the request message, calling the appropriate server procedure, and when it returns, marshalling the output arguments (or in the case of a failure, an error report) and making a reply message which it sends back to the client.
Through the concurrency provided by multi-threading, several RPC procedures can be occurring simllltaneously, in parallel, in the network. This is illustrated schematically in Figure 2 with multiple instances of each schematic block.
In OSF's DCE, the RPC interfaces support (among other things):
1. network and transport protocols that may be connectionless or connection-oriented;
2. similar and dissimilar hardware and/or operating systems;
3. use of commonly-supported (networked) data types, regardless of the application programming language, machines' native data representations (e.g., big or little endian), or code page (e.g., ASCII and various EBCDIC code pages~.
4. packing and unpacking of procedure input and output parameters (i.e., marshalling and unmarshalling) for transport across the network by software stubs; and 5. other related features, such as authentication of the applications involved, as well as authorizations for access to the various distributed resources within the network.
The present invention extends the RPC mechanism beyond the limits of a single distributed system by replacing the traditional system for effecting switched communications outside the LAN based On redirection of device driver commands with a high performance machine that utilises the RPC mechanism in a procedure for dynamically allocating and controlling the hardware resources used in effecting switched communications links between the distributed and possibly heterogeneous environments of LANs and WANs.
Although the preferred embodiment of the invention is described in relation to the DCE implementation of OSF, it is pointed out that the present invention is not limited to this implementation, but is applicable to any network that supports synchronous RPCs and multi-threading.
Figure 3 schematically il]ustrates the architecture of an active heterogeneous LAN with a switched communications gateway server and is representative of the type of heterogeneous environment to which the present invention is directed.
A LAN, generally designated by the numeral 30, consists of an electronic link 32 interconnecting single workstations 33 and 34, as well as different types of other local area networks 35, 36 and 37. As illustrated, networks 35 and 36 are examples of token ring LANs, and both networks 32 and 37 are examples of Ethernet LANs.
CA9-93-014 13 210 7 2 9 ~
In the case of networks 35 and 36, an intelligent device, such as a router 38a and 38b, connects the multiple workstations/processors ~generally denoted as 39 for network 35, and 40a and 40b for network 36) into the main LAN 32.
Network 37 connects workstations/processors 41a and 41b through a bridge 42 to the main LAN 32.
LAN applications may represent users that access remote server applications, such as users issuing outgoing calls.
LAN applications may also represent services that are used by remote users and/or applications that initiate incoming calls from the remote side of the switched network.
A single gateway server 43 includes multiple ports 44 for linking the incoming and outgoing calls between users and servers in the LAN with remote users 46 and servers 47 across the outside switched network 45.
The RPC interface required for implementing the present invention is of the generic type, requiring only systems support of synchronous RPCs, such as provided by OSF, and multi-threading programming interfaces, such as described in the IEEE POSIX specification referred to above. Therefore, this invention can be implemented on a variety of multi-threaded RPC network implementations.
According to the preferred embodiment of the present invention, a high performance machine for effecting switched communications through a LAN gateway is achieved by augmenting the generic RPC mechanism with a communications interface (an application programming interface or API) that permits the applications on the LAN to generate at least 3 concurrent threads of control for 3 different functional categories.
As illustrated in Figure 4, for an outgoing or incoming call ~request) through a switched LAN gateway, a client machine on a LAN issues an RPC 50 that goes through the client stub processing and network routines, as well as the LAN and the server network routines, as described earlier in relation to Figure 2. The RPC arrives at the server stub 51 with attendant procedure dispatch support, as described above. A
message is sent to the LAN Gateway Master Logic support 52, which locates and binds a physical port 54 for effecting the switched link 55. When the switched connection is established (e.g., an outgoing call has been successfully made or an incoming call has been received), the reverse path is traversed and the RPC response 53 is sent back to the client.
Through the use of RPCs, error messages for non-connection simply due to all physica] ports being occupied is avoided;
the RPC thread for a user's outgoing call can be suspended, where all ports are occupied, until a port becomes available, and the calling procedure at the user will never be aware of the delay. For incoming call request RPC, the client thread is suspended until an incoming call has been received and bound to port 54.
The LAN gateway maintains two data buffers for each DCE
client that re~uests use of a port; an output buffer for maintaining data characters to be transmitted to the switched network on behalf of the client and an input buffer for maintaining data characters that are received from the switched network for the client.
In the preferred embodiment, the three types of functional categories for control threads are defined as:
1. an Input (I) thread, that is dedicated to receiving input from the switched network;
2. an Output (0) thread, that is dedicated to sending output to the switched network; and 3. an Event (E) thread, that is used for receiving asynchronous as well as synchronous communications events, such as those detected by the gateway from its switched communications network side.
CA9-93-014 2 1 0 7 2 9 ~ 15 _.
Certain RPCs can be made from any of the threads, while others are allocated to one of the specific functional categories. The isolation of functions into distinct threads enables more efficient management of pointer and data structures at the gateway server. This yields high performance in the communications mechanism through providing concurrency for dissimilar functions and enforced serialization for similar functions.
Modifications in thread allocation can be incorporated so that different threads can be used to issue RPCs that belong to the same functional categories as long as the RPCs are issued serially to ensure continued enforcement of function serialization. For procedures that should be called from a designated thread, serialization can be enforced by a server return code whenever the server is executing another procedure.
In the preferred embodiment, the various standard functions related to switched communications links have been allocated between the three threads in the following manner. These functions are labelled with easily recognisable generic names, and their usual operations briefly defined.
procedures called from Input (I) thread Operation ReadData reads characters in the input buffer received from the switched communications network FlushInput discards the characters in the input buffer received from switched communications network procedures called from Output (O) thread Operation SendData appends characters to the output buffer for transmission to the switched network SendBreak specifies that a break signal is to be sent to the switched network TransImmediate expedites transmission of specified characters by~passing the output buffer DrainOutput transmits all characters in the output buffer before returning Flushoutput discards all characters in the output buffer procedures called from Event ~E) thread Operation ReadEvent block thread until specified event(s) occur procedures called from any thread Operation PortOpen call for use of a communications port ~returns a "handle" ) PortClose discontinue use of resources associated with the specified handle Program_Profile program communications port according to given input parameters Read_Profile read current profile of port -Connect switched network connectivity request (requires connection type for input or output, and, in the case of outgoing calls, requires switched network address, i.e., telephone number) Disconnect terminates switched communication Disconnect_Answer terminates switched communication and automatically sets port back into call-receiving mode All of the foregoing operations except PortOpen are performed in relation to a particular "handle" (address, type, etc.) that is returned by the DCE gateway server after processing the PortOpen call. It should also be recognised that until a switched link has been established, an error message will be returned on any of the buffer related calls.
In the present invention, the LAN workstations cannot access the ports directly, but only through RPCs. The Master Logic Support is the only "box" with access to the network, and it can easily be regulated for central compliance with any network restrictions. The Connect, Disconnect, Disconnect_Answer and Program_Profile functions are then capable of modifying the hardware characteristics of the ports to the switched networks.
Experimental Set-up In order to establish 1he workability of the proposed embodiment and to demonstrate its cost-efficiency over known LAN gateways, a prototype was set-up to simulate a LAN
2 1 0729~
gateway environment. Some features included in the experimental set-up relate to my concurrently filed application entitled "A Method and Mechanism for Allocating Switched Communications Ports in a Heterogeneous Data Processing Network Gateway" (docket no. CA9-93-015), the disclosure of which is hereby incorporated herein by reference.
Three workstations running the Distributed Computing Environment (DCE) of the Open Software Foundation (OSF) on a LAN were used in this experimental set-up. One workstation was for clients issuing incoming switched calls, a second was for clients issuing outgoing switched calls and a third for running a server emulating a LAN gateway. Multiple threads within one process were used to simulate multiple clients.
The gateway server was configured to allow for multiple parallel executor threads (up to four times the number of assumed ports in the gateway). The threads were triggered by the scheduling of arrived RPCs for execution, and each thread could run a single RPC at a time.
It is also pointed out that in the case of the particular release of the OSF DCE implementation, only a fixed number of outstanding RPCs are permitted at the server at any one time due to hard-coded limits on the environment for which DCE is configured, although during the experiment, the number of RPC retries by clients never reached one percent for each RPC.
The clients simulating requests for incoming calls communicated with the gateway server over connection-oriented (TCP/IP - Transmission Control Protocol/Internet Protocol) LAN connections, while other clients (those issuing simulated outgoing calls) used datagrams (UDP/IP - User Datagram Protocol/Internet Protocol).
The server also collected statistics for analyzing the workability and efficiency of the proposed system.
A timer thread 56 (Figure 4) was used to simulate incoming calls from a switched network to the server. Upon waking up by the system following a sleep time corresponding to interarrival of calls, this single thread looked up the status of ports. If it did not find a port waiting for an incoming call, it would then record a switched call "loss";
otherwise, it would notify the Master Logic Support to bind the switched call to an RPC client that is awaiting a call (in this case, an incoming switched call "success" is recorded).
Figure 5 illustrates the simulation of clients issuing outgoing calls. After starting the workstation 60, common variables and protocols were initiated 61. Multiple independent threads were issued 62 to simulated multiple user devices seeking to issue multiple outgoing calls through the gateway server. For each single simulated device started 63, the thread was put to sleep for a random period of time 64 to simu]ate the random access to the gateway's resources from a real LAN set-up.
After "waking" the device thread 65, a thread for sequential procedure calls for each thread simulating a single connection request was dispatched 66. A procedure PortOpen call was issued to the gateway server for each simulated client application thread 67.
The procedure call for each PortOpen command 67 issued by the client to the gateway server actually called a previously generated procedure stub. The call returned a handle from the server. The client then issued a Connect(out) 68 to the gateway that returned when a simulated successful outgoing call was established. The procedure call thread was then "put to sleep" for a random period of time 69 (to simulate random connection time between the LAN workstation application and a remote server), after which Disconnect and PortClose commands 70 and 71 were sequentially issued with the same handle before the thread was terminated 72.
A simulation of an incoming call is illustrated in Figure 6.
After starting this workstation 74, common variables and protocols were again assigned 75, and multiple independent child threads (corresponding to the number of simulated ports) to simulate LAN servers for remote clients on a switched network, dispatched 76, while the main thread remained in control forever 77.
After start of each dispatched thread 78, a PortOpen call was issued to the gateway server to receive a handle 79.
Then, a Connect(in) 80 was sent message to the gateway server; this RPC returned when a simulated incoming call had been successfully established.
To simulate data transmission over the established switched link, the thread was "put to sleep" for a random period of time 81. After "waking", the thread issued a Disconnect_Answer command 82 to simulate the immediate reoccupation of a port after disconnection. This procedure was repeated several times in the course of the experiment.
When long duration runs on the experimental set-up were made, it was found that the high performance machine proposed herein effectively provided concurrency in establishing switched communications links through a LAN
gateway server, freeing hardware resources of the LAN not immediately involved in maintaining the switched links.
The gateway interface of the present invention is described in this application in use in a specific type of LAN
architecture. It will be clearly recognized, however, that with appropriate modifications that would be obvious from the present description to a person skilled in the art, that the interface is portable and may be adapted for connecting other types of area networks having similar gateway characteristics.
The present invention extends the RPC mechanism beyond the limits of a single distributed system by replacing the traditional system for effecting switched communications outside the LAN based On redirection of device driver commands with a high performance machine that utilises the RPC mechanism in a procedure for dynamically allocating and controlling the hardware resources used in effecting switched communications links between the distributed and possibly heterogeneous environments of LANs and WANs.
Although the preferred embodiment of the invention is described in relation to the DCE implementation of OSF, it is pointed out that the present invention is not limited to this implementation, but is applicable to any network that supports synchronous RPCs and multi-threading.
Figure 3 schematically il]ustrates the architecture of an active heterogeneous LAN with a switched communications gateway server and is representative of the type of heterogeneous environment to which the present invention is directed.
A LAN, generally designated by the numeral 30, consists of an electronic link 32 interconnecting single workstations 33 and 34, as well as different types of other local area networks 35, 36 and 37. As illustrated, networks 35 and 36 are examples of token ring LANs, and both networks 32 and 37 are examples of Ethernet LANs.
CA9-93-014 13 210 7 2 9 ~
In the case of networks 35 and 36, an intelligent device, such as a router 38a and 38b, connects the multiple workstations/processors ~generally denoted as 39 for network 35, and 40a and 40b for network 36) into the main LAN 32.
Network 37 connects workstations/processors 41a and 41b through a bridge 42 to the main LAN 32.
LAN applications may represent users that access remote server applications, such as users issuing outgoing calls.
LAN applications may also represent services that are used by remote users and/or applications that initiate incoming calls from the remote side of the switched network.
A single gateway server 43 includes multiple ports 44 for linking the incoming and outgoing calls between users and servers in the LAN with remote users 46 and servers 47 across the outside switched network 45.
The RPC interface required for implementing the present invention is of the generic type, requiring only systems support of synchronous RPCs, such as provided by OSF, and multi-threading programming interfaces, such as described in the IEEE POSIX specification referred to above. Therefore, this invention can be implemented on a variety of multi-threaded RPC network implementations.
According to the preferred embodiment of the present invention, a high performance machine for effecting switched communications through a LAN gateway is achieved by augmenting the generic RPC mechanism with a communications interface (an application programming interface or API) that permits the applications on the LAN to generate at least 3 concurrent threads of control for 3 different functional categories.
As illustrated in Figure 4, for an outgoing or incoming call ~request) through a switched LAN gateway, a client machine on a LAN issues an RPC 50 that goes through the client stub processing and network routines, as well as the LAN and the server network routines, as described earlier in relation to Figure 2. The RPC arrives at the server stub 51 with attendant procedure dispatch support, as described above. A
message is sent to the LAN Gateway Master Logic support 52, which locates and binds a physical port 54 for effecting the switched link 55. When the switched connection is established (e.g., an outgoing call has been successfully made or an incoming call has been received), the reverse path is traversed and the RPC response 53 is sent back to the client.
Through the use of RPCs, error messages for non-connection simply due to all physica] ports being occupied is avoided;
the RPC thread for a user's outgoing call can be suspended, where all ports are occupied, until a port becomes available, and the calling procedure at the user will never be aware of the delay. For incoming call request RPC, the client thread is suspended until an incoming call has been received and bound to port 54.
The LAN gateway maintains two data buffers for each DCE
client that re~uests use of a port; an output buffer for maintaining data characters to be transmitted to the switched network on behalf of the client and an input buffer for maintaining data characters that are received from the switched network for the client.
In the preferred embodiment, the three types of functional categories for control threads are defined as:
1. an Input (I) thread, that is dedicated to receiving input from the switched network;
2. an Output (0) thread, that is dedicated to sending output to the switched network; and 3. an Event (E) thread, that is used for receiving asynchronous as well as synchronous communications events, such as those detected by the gateway from its switched communications network side.
CA9-93-014 2 1 0 7 2 9 ~ 15 _.
Certain RPCs can be made from any of the threads, while others are allocated to one of the specific functional categories. The isolation of functions into distinct threads enables more efficient management of pointer and data structures at the gateway server. This yields high performance in the communications mechanism through providing concurrency for dissimilar functions and enforced serialization for similar functions.
Modifications in thread allocation can be incorporated so that different threads can be used to issue RPCs that belong to the same functional categories as long as the RPCs are issued serially to ensure continued enforcement of function serialization. For procedures that should be called from a designated thread, serialization can be enforced by a server return code whenever the server is executing another procedure.
In the preferred embodiment, the various standard functions related to switched communications links have been allocated between the three threads in the following manner. These functions are labelled with easily recognisable generic names, and their usual operations briefly defined.
procedures called from Input (I) thread Operation ReadData reads characters in the input buffer received from the switched communications network FlushInput discards the characters in the input buffer received from switched communications network procedures called from Output (O) thread Operation SendData appends characters to the output buffer for transmission to the switched network SendBreak specifies that a break signal is to be sent to the switched network TransImmediate expedites transmission of specified characters by~passing the output buffer DrainOutput transmits all characters in the output buffer before returning Flushoutput discards all characters in the output buffer procedures called from Event ~E) thread Operation ReadEvent block thread until specified event(s) occur procedures called from any thread Operation PortOpen call for use of a communications port ~returns a "handle" ) PortClose discontinue use of resources associated with the specified handle Program_Profile program communications port according to given input parameters Read_Profile read current profile of port -Connect switched network connectivity request (requires connection type for input or output, and, in the case of outgoing calls, requires switched network address, i.e., telephone number) Disconnect terminates switched communication Disconnect_Answer terminates switched communication and automatically sets port back into call-receiving mode All of the foregoing operations except PortOpen are performed in relation to a particular "handle" (address, type, etc.) that is returned by the DCE gateway server after processing the PortOpen call. It should also be recognised that until a switched link has been established, an error message will be returned on any of the buffer related calls.
In the present invention, the LAN workstations cannot access the ports directly, but only through RPCs. The Master Logic Support is the only "box" with access to the network, and it can easily be regulated for central compliance with any network restrictions. The Connect, Disconnect, Disconnect_Answer and Program_Profile functions are then capable of modifying the hardware characteristics of the ports to the switched networks.
Experimental Set-up In order to establish 1he workability of the proposed embodiment and to demonstrate its cost-efficiency over known LAN gateways, a prototype was set-up to simulate a LAN
2 1 0729~
gateway environment. Some features included in the experimental set-up relate to my concurrently filed application entitled "A Method and Mechanism for Allocating Switched Communications Ports in a Heterogeneous Data Processing Network Gateway" (docket no. CA9-93-015), the disclosure of which is hereby incorporated herein by reference.
Three workstations running the Distributed Computing Environment (DCE) of the Open Software Foundation (OSF) on a LAN were used in this experimental set-up. One workstation was for clients issuing incoming switched calls, a second was for clients issuing outgoing switched calls and a third for running a server emulating a LAN gateway. Multiple threads within one process were used to simulate multiple clients.
The gateway server was configured to allow for multiple parallel executor threads (up to four times the number of assumed ports in the gateway). The threads were triggered by the scheduling of arrived RPCs for execution, and each thread could run a single RPC at a time.
It is also pointed out that in the case of the particular release of the OSF DCE implementation, only a fixed number of outstanding RPCs are permitted at the server at any one time due to hard-coded limits on the environment for which DCE is configured, although during the experiment, the number of RPC retries by clients never reached one percent for each RPC.
The clients simulating requests for incoming calls communicated with the gateway server over connection-oriented (TCP/IP - Transmission Control Protocol/Internet Protocol) LAN connections, while other clients (those issuing simulated outgoing calls) used datagrams (UDP/IP - User Datagram Protocol/Internet Protocol).
The server also collected statistics for analyzing the workability and efficiency of the proposed system.
A timer thread 56 (Figure 4) was used to simulate incoming calls from a switched network to the server. Upon waking up by the system following a sleep time corresponding to interarrival of calls, this single thread looked up the status of ports. If it did not find a port waiting for an incoming call, it would then record a switched call "loss";
otherwise, it would notify the Master Logic Support to bind the switched call to an RPC client that is awaiting a call (in this case, an incoming switched call "success" is recorded).
Figure 5 illustrates the simulation of clients issuing outgoing calls. After starting the workstation 60, common variables and protocols were initiated 61. Multiple independent threads were issued 62 to simulated multiple user devices seeking to issue multiple outgoing calls through the gateway server. For each single simulated device started 63, the thread was put to sleep for a random period of time 64 to simu]ate the random access to the gateway's resources from a real LAN set-up.
After "waking" the device thread 65, a thread for sequential procedure calls for each thread simulating a single connection request was dispatched 66. A procedure PortOpen call was issued to the gateway server for each simulated client application thread 67.
The procedure call for each PortOpen command 67 issued by the client to the gateway server actually called a previously generated procedure stub. The call returned a handle from the server. The client then issued a Connect(out) 68 to the gateway that returned when a simulated successful outgoing call was established. The procedure call thread was then "put to sleep" for a random period of time 69 (to simulate random connection time between the LAN workstation application and a remote server), after which Disconnect and PortClose commands 70 and 71 were sequentially issued with the same handle before the thread was terminated 72.
A simulation of an incoming call is illustrated in Figure 6.
After starting this workstation 74, common variables and protocols were again assigned 75, and multiple independent child threads (corresponding to the number of simulated ports) to simulate LAN servers for remote clients on a switched network, dispatched 76, while the main thread remained in control forever 77.
After start of each dispatched thread 78, a PortOpen call was issued to the gateway server to receive a handle 79.
Then, a Connect(in) 80 was sent message to the gateway server; this RPC returned when a simulated incoming call had been successfully established.
To simulate data transmission over the established switched link, the thread was "put to sleep" for a random period of time 81. After "waking", the thread issued a Disconnect_Answer command 82 to simulate the immediate reoccupation of a port after disconnection. This procedure was repeated several times in the course of the experiment.
When long duration runs on the experimental set-up were made, it was found that the high performance machine proposed herein effectively provided concurrency in establishing switched communications links through a LAN
gateway server, freeing hardware resources of the LAN not immediately involved in maintaining the switched links.
The gateway interface of the present invention is described in this application in use in a specific type of LAN
architecture. It will be clearly recognized, however, that with appropriate modifications that would be obvious from the present description to a person skilled in the art, that the interface is portable and may be adapted for connecting other types of area networks having similar gateway characteristics.
Claims (6)
1. An interface mechanism for a switched communications gateway in a distributed computing network comprising:
means for issuing multiple remote procedures calls between as least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
said means for concurrently processing the multiple remote calls including means for concurrently issuing at least three separate threads of control between said at least one computer and the gateway across the distributed system; said means for issuing at least three separate threads of control including means for issuing a first thread of control for functions related to receiving incoming data from a switched network;
means for issuing a second thread of control for functions related to sending data to a switched network;
means for issuing a third thread of control of functions related to opening and closing switched ports on the gateway;
means for identifying related functions;
means for assigning related functions to a same thread of control;
means for identifying remote procedure calls for related functions; and scheduling means for sequentially processing remote procedure calls for the related functions at the gateway.
means for issuing multiple remote procedures calls between as least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
said means for concurrently processing the multiple remote calls including means for concurrently issuing at least three separate threads of control between said at least one computer and the gateway across the distributed system; said means for issuing at least three separate threads of control including means for issuing a first thread of control for functions related to receiving incoming data from a switched network;
means for issuing a second thread of control for functions related to sending data to a switched network;
means for issuing a third thread of control of functions related to opening and closing switched ports on the gateway;
means for identifying related functions;
means for assigning related functions to a same thread of control;
means for identifying remote procedure calls for related functions; and scheduling means for sequentially processing remote procedure calls for the related functions at the gateway.
2. An interface mechanism for a switched communications gateway in a distributed computing network comprising:
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
means for identifying remote procedure calls for related functions;
scheduling means for sequentially processing remote procedure calls for the related functions at the gateway; and means responsive to a remote procedure call for locating an idle switched port in the gateway and for binding the remote procedure call to the located port.
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
means for identifying remote procedure calls for related functions;
scheduling means for sequentially processing remote procedure calls for the related functions at the gateway; and means responsive to a remote procedure call for locating an idle switched port in the gateway and for binding the remote procedure call to the located port.
3. An interface, according to claim 27 wherein the means for locating an idle switched port include means for differentiating between ports set for incoming and outgoing switched calls through the gateway, and between remote procedure calls requesting incoming and outgoing switched calls through the gateway.
4. An interface mechanism for a switched communications gateway in a heterogeneous distributed computing network comprising:
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
said means for concurrently processing the multiple remote procedure calls including means for concurrently issuing at least three separate threads of control between said at least one computer and the gateway across the distributed system;
said means for concurrently issuing at least three separate threads of control including means for issuing a first thread of control for functions related to receiving incoming data from a switched network;
means for issuing a second thread of control for functions related to sending data to a switched network;
means for issuing a third thread of control for functions related to opening anddosing switched ports in the gateway;
means for identifying related functions;
means for assigning related functions to a same thread of control;
means for identifying remote procedure calls for related functions; and scheduling means for sequentially processing remote procedure calls for the related functions at the gateway.
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
said means for concurrently processing the multiple remote procedure calls including means for concurrently issuing at least three separate threads of control between said at least one computer and the gateway across the distributed system;
said means for concurrently issuing at least three separate threads of control including means for issuing a first thread of control for functions related to receiving incoming data from a switched network;
means for issuing a second thread of control for functions related to sending data to a switched network;
means for issuing a third thread of control for functions related to opening anddosing switched ports in the gateway;
means for identifying related functions;
means for assigning related functions to a same thread of control;
means for identifying remote procedure calls for related functions; and scheduling means for sequentially processing remote procedure calls for the related functions at the gateway.
5. An interface mechanism for a switched communications gateway in a heterogeneous distributed computing network comprising:
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
means for identifying remote procedure calls for related functions;
scheduling means for sequentially processing remote procedure calls for the related functions at the gateway; and means responsive to a remote procedure call for locating an idle switched port in the gateway and for binding the remote procedure call to the located port.
means for issuing multiple remote procedures calls between at least one computer and the gateway across the distributed network;
means for concurrently processing the multiple remote procedure calls between said at least one computer and the gateway across the distributed network;
means for identifying remote procedure calls for related functions;
scheduling means for sequentially processing remote procedure calls for the related functions at the gateway; and means responsive to a remote procedure call for locating an idle switched port in the gateway and for binding the remote procedure call to the located port.
6. An interface, according to claim 5, wherein the means for locating an idle switched port include means for differentiating between ports set for incoming and outgoing switched calls through the gateway, and between remote procedure calls requesting incoming and outgoing switched calls through the gateway.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002107299A CA2107299C (en) | 1993-09-29 | 1993-09-29 | High performance machine for switched communications in a heterogenous data processing network gateway |
| US08/131,059 US5463625A (en) | 1993-09-29 | 1993-10-01 | High performance machine for switched communications in a heterogeneous data processing network gateway |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002107299A CA2107299C (en) | 1993-09-29 | 1993-09-29 | High performance machine for switched communications in a heterogenous data processing network gateway |
| US08/131,059 US5463625A (en) | 1993-09-29 | 1993-10-01 | High performance machine for switched communications in a heterogeneous data processing network gateway |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2107299A1 CA2107299A1 (en) | 1995-03-30 |
| CA2107299C true CA2107299C (en) | 1997-02-25 |
Family
ID=25676694
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002107299A Expired - Fee Related CA2107299C (en) | 1993-09-29 | 1993-09-29 | High performance machine for switched communications in a heterogenous data processing network gateway |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5463625A (en) |
| CA (1) | CA2107299C (en) |
Families Citing this family (114)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0669020B1 (en) * | 1992-11-13 | 1997-04-02 | Microsoft Corporation | Methods for marshalling interface pointers for remote procedure calls |
| US6289390B1 (en) * | 1993-08-18 | 2001-09-11 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| US5596579A (en) * | 1993-10-01 | 1997-01-21 | International Business Machines Corporation | High performance machine for switched communications in a heterogeneous data processing network gateway |
| US6141689A (en) * | 1993-10-01 | 2000-10-31 | International Business Machines Corp. | Method and mechanism for allocating switched communications ports in a heterogeneous data processing network gateway |
| FR2714746B1 (en) * | 1993-12-31 | 1996-02-02 | Bull Sa | Method for simulating a "server" architecture from a "client" architecture. |
| WO1995025311A1 (en) * | 1994-03-15 | 1995-09-21 | Digi International Inc. | System and method for communication with a remote network device |
| FR2722591B1 (en) * | 1994-07-13 | 1996-08-30 | Bull Sa | OPEN COMPUTER SYSTEM WITH MULTIPLE SERVERS |
| SE503633C2 (en) * | 1994-10-17 | 1996-07-22 | Ericsson Telefon Ab L M | Load sharing system and method for processing data as well as communication system with load sharing |
| US5761425A (en) * | 1994-12-02 | 1998-06-02 | Compuserve Incorporated | System for facilitating data transfers between host computers and workstations by having a first, second and third computer programs communicate in a matching application-level protocol |
| EP0718784B1 (en) * | 1994-12-20 | 2003-08-27 | Sun Microsystems, Inc. | Method and system for the retrieval of personalized information |
| US6182108B1 (en) | 1995-01-31 | 2001-01-30 | Microsoft Corporation | Method and system for multi-threaded processing |
| US6249822B1 (en) | 1995-04-24 | 2001-06-19 | Microsoft Corporation | Remote procedure call method |
| US6901433B2 (en) * | 1995-06-07 | 2005-05-31 | Microsoft Corporation | System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service |
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
| US5933599A (en) * | 1995-07-17 | 1999-08-03 | Microsoft Corporation | Apparatus for presenting the content of an interactive on-line network |
| US20020178051A1 (en) | 1995-07-25 | 2002-11-28 | Thomas G. Scavone | Interactive marketing network and process using electronic certificates |
| US5941947A (en) * | 1995-08-18 | 1999-08-24 | Microsoft Corporation | System and method for controlling access to data entities in a computer network |
| US5956509A (en) | 1995-08-18 | 1999-09-21 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| US6108704A (en) * | 1995-09-25 | 2000-08-22 | Netspeak Corporation | Point-to-point internet protocol |
| US6009469A (en) * | 1995-09-25 | 1999-12-28 | Netspeak Corporation | Graphic user interface for internet telephony application |
| US6226678B1 (en) | 1995-09-25 | 2001-05-01 | Netspeak Corporation | Method and apparatus for dynamically defining data communication utilities |
| US6185184B1 (en) | 1995-09-25 | 2001-02-06 | Netspeak Corporation | Directory server for providing dynamically assigned network protocol addresses |
| US5764887A (en) * | 1995-12-11 | 1998-06-09 | International Business Machines Corporation | System and method for supporting distributed computing mechanisms in a local area network server environment |
| US5732078A (en) * | 1996-01-16 | 1998-03-24 | Bell Communications Research, Inc. | On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network |
| AU710463B2 (en) * | 1996-02-16 | 1999-09-23 | Corning Incorporated | A symmetric, dispersion-manager fiber optic cable and system |
| US5751706A (en) * | 1996-06-05 | 1998-05-12 | Cignal Global Communications, Inc. | System and method for establishing a call telecommunications path |
| US5748897A (en) * | 1996-07-02 | 1998-05-05 | Sun Microsystems, Inc. | Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer |
| GB9620196D0 (en) * | 1996-09-27 | 1996-11-13 | British Telecomm | Distributed processing |
| GB2320594A (en) * | 1996-12-20 | 1998-06-24 | Ibm | Dispatching client method calls to parallel execution threads within a server |
| US5951653A (en) * | 1997-01-29 | 1999-09-14 | Microsoft Corporation | Method and system for coordinating access to objects of different thread types in a shared memory space |
| US6226689B1 (en) * | 1997-01-29 | 2001-05-01 | Microsoft Corporation | Method and mechanism for interprocess communication using client and server listening threads |
| US6654933B1 (en) | 1999-09-21 | 2003-11-25 | Kasenna, Inc. | System and method for media stream indexing |
| US6167423A (en) * | 1997-04-03 | 2000-12-26 | Microsoft Corporation | Concurrency control of state machines in a computer system using cliques |
| US6078964A (en) * | 1997-08-29 | 2000-06-20 | International Business Machines Corporation | Establishing direct communications between two hosts without using a high performance LAN connection |
| US5999974A (en) * | 1997-08-29 | 1999-12-07 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US6014699A (en) * | 1997-08-29 | 2000-01-11 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US6023734A (en) * | 1997-08-29 | 2000-02-08 | International Business Corporation | Establishing direct communications between two hosts without using a high performance LAN connection |
| US5974049A (en) * | 1997-08-29 | 1999-10-26 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US6003080A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6003088A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Blocking IP datagrams in a multi-path channel point-to-point environment |
| US6084859A (en) * | 1997-08-29 | 2000-07-04 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6009467A (en) * | 1997-08-29 | 1999-12-28 | International Business Machines Corporation | System for checking status of supported functions of communication platforms at preselected intervals in order to allow hosts to obtain updated list of all supported functions |
| US6006261A (en) * | 1997-08-29 | 1999-12-21 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US5987515A (en) * | 1997-08-29 | 1999-11-16 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6185218B1 (en) | 1997-08-29 | 2001-02-06 | International Business Machines Corporation | Communication method and apparatus for use in a computing network environment having high performance LAN connections |
| US7076784B1 (en) | 1997-10-28 | 2006-07-11 | Microsoft Corporation | Software component execution management using context objects for tracking externally-defined intrinsic properties of executing software components within an execution environment |
| US6134594A (en) | 1997-10-28 | 2000-10-17 | Microsoft Corporation | Multi-user, multiple tier distributed application architecture with single-user access control of middle tier objects |
| US6098101A (en) * | 1997-12-11 | 2000-08-01 | Micron Electronics, Inc. | Method and apparatus for generating shared modem usage reports in a networked computer system |
| JP3224521B2 (en) * | 1998-02-20 | 2001-10-29 | 日本電信電話株式会社 | Communication control method for FC / ATM composite network and inter-network connection device |
| US6154751A (en) * | 1998-05-14 | 2000-11-28 | International Business Machines Corporation | Method for executing a user-requested CGI program in a new authentication context while protecting operation of a default web server program |
| US6425017B1 (en) | 1998-08-17 | 2002-07-23 | Microsoft Corporation | Queued method invocations on distributed component applications |
| US7305451B2 (en) * | 1998-08-24 | 2007-12-04 | Microsoft Corporation | System for providing users an integrated directory service containing content nodes located in different groups of application servers in computer network |
| US6327621B1 (en) | 1998-08-25 | 2001-12-04 | International Business Machines Corporation | Method for shared multicast interface in a multi-partition environment |
| US6490285B2 (en) | 1998-08-25 | 2002-12-03 | International Business Machines Corporation | IP multicast interface |
| US6600743B1 (en) | 1998-08-25 | 2003-07-29 | International Business Machines Corporation | IP multicast interface |
| US6574736B1 (en) | 1998-11-30 | 2003-06-03 | Microsoft Corporation | Composable roles |
| US6487665B1 (en) | 1998-11-30 | 2002-11-26 | Microsoft Corporation | Object security boundaries |
| US6385724B1 (en) | 1998-11-30 | 2002-05-07 | Microsoft Corporation | Automatic object caller chain with declarative impersonation and transitive trust |
| US7216348B1 (en) | 1999-01-05 | 2007-05-08 | Net2Phone, Inc. | Method and apparatus for dynamically balancing call flow workloads in a telecommunications system |
| US6748455B1 (en) | 1999-02-23 | 2004-06-08 | Microsoft Corporation | Object connectivity through loosely coupled publish and subscribe events with filtering |
| US6829770B1 (en) | 1999-02-23 | 2004-12-07 | Microsoft Corporation | Object connectivity through loosely coupled publish and subscribe events |
| US20060034275A1 (en) | 2000-05-03 | 2006-02-16 | At&T Laboratories-Cambridge Ltd. | Data transfer, synchronising applications, and low latency networks |
| US6427196B1 (en) | 1999-08-31 | 2002-07-30 | Intel Corporation | SRAM controller for parallel processor architecture including address and command queue and arbiter |
| US6668317B1 (en) | 1999-08-31 | 2003-12-23 | Intel Corporation | Microengine for parallel processor architecture |
| US6983350B1 (en) | 1999-08-31 | 2006-01-03 | Intel Corporation | SDRAM controller for parallel processor architecture |
| EP1236093A4 (en) | 1999-09-01 | 2006-07-26 | Intel Corp | Branch instruction for processor architecture |
| US7546444B1 (en) | 1999-09-01 | 2009-06-09 | Intel Corporation | Register set used in multithreaded parallel processor architecture |
| US7191309B1 (en) | 1999-09-01 | 2007-03-13 | Intel Corporation | Double shift instruction for micro engine used in multithreaded parallel processor architecture |
| DE19957594B4 (en) * | 1999-11-30 | 2004-08-26 | OCé PRINTING SYSTEMS GMBH | Method for synchronizing threads of a computer program |
| US6920636B1 (en) * | 1999-12-15 | 2005-07-19 | Microsoft Corporation | Queued component interface passing for results outflow from queued method invocations |
| US6532509B1 (en) | 1999-12-22 | 2003-03-11 | Intel Corporation | Arbitrating command requests in a parallel multi-threaded processing system |
| US6694380B1 (en) | 1999-12-27 | 2004-02-17 | Intel Corporation | Mapping requests from a processing unit that uses memory-mapped input-output space |
| US6631430B1 (en) | 1999-12-28 | 2003-10-07 | Intel Corporation | Optimizations to receive packet status from fifo bus |
| US7620702B1 (en) | 1999-12-28 | 2009-11-17 | Intel Corporation | Providing real-time control data for a network processor |
| US6625654B1 (en) | 1999-12-28 | 2003-09-23 | Intel Corporation | Thread signaling in multi-threaded network processor |
| US6307789B1 (en) | 1999-12-28 | 2001-10-23 | Intel Corporation | Scratchpad memory |
| US6661794B1 (en) | 1999-12-29 | 2003-12-09 | Intel Corporation | Method and apparatus for gigabit packet assignment for multithreaded packet processing |
| US6952824B1 (en) | 1999-12-30 | 2005-10-04 | Intel Corporation | Multi-threaded sequenced receive for fast network port stream of packets |
| US7480706B1 (en) | 1999-12-30 | 2009-01-20 | Intel Corporation | Multi-threaded round-robin receive for fast network port |
| US6976095B1 (en) * | 1999-12-30 | 2005-12-13 | Intel Corporation | Port blocking technique for maintaining receive packet ordering for a multiple ethernet port switch |
| US6584522B1 (en) | 1999-12-30 | 2003-06-24 | Intel Corporation | Communication between processors |
| US6407341B1 (en) | 2000-04-25 | 2002-06-18 | International Business Machines Corporation | Conductive substructures of a multilayered laminate |
| US6917988B1 (en) * | 2000-08-31 | 2005-07-12 | International Business Machines Corporation | System and method for efficient management of fibre channel communication |
| US7681018B2 (en) * | 2000-08-31 | 2010-03-16 | Intel Corporation | Method and apparatus for providing large register address space while maximizing cycletime performance for a multi-threaded register file set |
| US20020053017A1 (en) * | 2000-09-01 | 2002-05-02 | Adiletta Matthew J. | Register instructions for a multithreaded processor |
| US7020871B2 (en) * | 2000-12-21 | 2006-03-28 | Intel Corporation | Breakpoint method for parallel hardware threads in multithreaded processor |
| US6868476B2 (en) | 2001-08-27 | 2005-03-15 | Intel Corporation | Software controlled content addressable memory in a general purpose execution datapath |
| US7487505B2 (en) | 2001-08-27 | 2009-02-03 | Intel Corporation | Multithreaded microprocessor with register allocation based on number of active threads |
| US7225281B2 (en) | 2001-08-27 | 2007-05-29 | Intel Corporation | Multiprocessor infrastructure for providing flexible bandwidth allocation via multiple instantiations of separate data buses, control buses and support mechanisms |
| US7216204B2 (en) * | 2001-08-27 | 2007-05-08 | Intel Corporation | Mechanism for providing early coherency detection to enable high performance memory updates in a latency sensitive multithreaded environment |
| US7126952B2 (en) | 2001-09-28 | 2006-10-24 | Intel Corporation | Multiprotocol decapsulation/encapsulation control structure and packet protocol conversion method |
| US7158964B2 (en) * | 2001-12-12 | 2007-01-02 | Intel Corporation | Queue management |
| US7107413B2 (en) * | 2001-12-17 | 2006-09-12 | Intel Corporation | Write queue descriptor count instruction for high speed queuing |
| US7269179B2 (en) * | 2001-12-18 | 2007-09-11 | Intel Corporation | Control mechanisms for enqueue and dequeue operations in a pipelined network processor |
| US7895239B2 (en) | 2002-01-04 | 2011-02-22 | Intel Corporation | Queue arrays in network devices |
| US7181573B2 (en) * | 2002-01-07 | 2007-02-20 | Intel Corporation | Queue array caching in network devices |
| US6934951B2 (en) | 2002-01-17 | 2005-08-23 | Intel Corporation | Parallel processor with functional pipeline providing programming engines by supporting multiple contexts and critical section |
| US7610451B2 (en) | 2002-01-25 | 2009-10-27 | Intel Corporation | Data transfer mechanism using unidirectional pull bus and push bus |
| US7181594B2 (en) * | 2002-01-25 | 2007-02-20 | Intel Corporation | Context pipelines |
| US7149226B2 (en) * | 2002-02-01 | 2006-12-12 | Intel Corporation | Processing data packets |
| US7437724B2 (en) * | 2002-04-03 | 2008-10-14 | Intel Corporation | Registers for data transfers |
| US7471688B2 (en) | 2002-06-18 | 2008-12-30 | Intel Corporation | Scheduling system for transmission of cells to ATM virtual circuits and DSL ports |
| US7337275B2 (en) | 2002-08-13 | 2008-02-26 | Intel Corporation | Free list and ring data structure management |
| US7352769B2 (en) | 2002-09-12 | 2008-04-01 | Intel Corporation | Multiple calendar schedule reservation structure and method |
| US7433307B2 (en) | 2002-11-05 | 2008-10-07 | Intel Corporation | Flow control in a network environment |
| US6941438B2 (en) * | 2003-01-10 | 2005-09-06 | Intel Corporation | Memory interleaving |
| WO2004095278A1 (en) * | 2003-04-15 | 2004-11-04 | Thomson Licensing S.A. | Method and apparatus for router port configuration |
| US7493513B2 (en) * | 2003-04-29 | 2009-02-17 | International Business Machines Corporation | Automatically freezing functionality of a computing entity responsive to an error |
| US7443836B2 (en) | 2003-06-16 | 2008-10-28 | Intel Corporation | Processing a data packet |
| US7213099B2 (en) | 2003-12-30 | 2007-05-01 | Intel Corporation | Method and apparatus utilizing non-uniformly distributed DRAM configurations and to detect in-range memory address matches |
| US7676811B2 (en) * | 2006-03-23 | 2010-03-09 | Microsoft Corporation | Ensuring thread affinity for interprocess communication in a managed code environment |
| US9094343B1 (en) * | 2008-11-13 | 2015-07-28 | Qlogic, Corporation | Method and system for taking a network port offline |
| US8775245B2 (en) | 2010-02-11 | 2014-07-08 | News America Marketing Properties, Llc | Secure coupon distribution |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4417244A (en) * | 1981-09-01 | 1983-11-22 | International Business Machines Corp. | Automatic path rearrangement for blocking switching matrix |
| US4972368A (en) * | 1988-03-04 | 1990-11-20 | Stallion Technologies, Pty. Ltd. | Intelligent serial I/O subsystem |
| US4897874A (en) * | 1988-03-31 | 1990-01-30 | American Telephone And Telegraph Company At&T Bell Laboratories | Metropolitan area network arrangement for serving virtual data networks |
| US4958341A (en) * | 1988-03-31 | 1990-09-18 | At&T Bell Laboratories | Integrated packetized voice and data switching system |
| US4896319A (en) * | 1988-03-31 | 1990-01-23 | American Telephone And Telegraph Company, At&T Bell Laboratories | Identification and authentication of end user systems for packet communications network services |
| FR2635243B1 (en) * | 1988-08-05 | 1994-01-14 | Lmt Radio Professionnelle | PACKET SWITCHER FOR ASYNCHRONOUS DATA TRANSFER IN A DIGITAL TRANSMISSION NETWORK |
| US5249293A (en) * | 1989-06-27 | 1993-09-28 | Digital Equipment Corporation | Computer network providing transparent operation on a compute server and associated method |
| US5247676A (en) * | 1989-06-29 | 1993-09-21 | Digital Equipment Corporation | RPC based computer system using transparent callback and associated method |
| US5179702A (en) * | 1989-12-29 | 1993-01-12 | Supercomputer Systems Limited Partnership | System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling |
| US5144293A (en) * | 1990-12-18 | 1992-09-01 | International Business Machines Corporation | Serial link communication system with cascaded switches |
| GB9104861D0 (en) * | 1991-03-07 | 1991-04-17 | Univ Strathclyde | Communications switching network |
| US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
-
1993
- 1993-09-29 CA CA002107299A patent/CA2107299C/en not_active Expired - Fee Related
- 1993-10-01 US US08/131,059 patent/US5463625A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2107299A1 (en) | 1995-03-30 |
| US5463625A (en) | 1995-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2107299C (en) | High performance machine for switched communications in a heterogenous data processing network gateway | |
| US5596579A (en) | High performance machine for switched communications in a heterogeneous data processing network gateway | |
| US6141689A (en) | Method and mechanism for allocating switched communications ports in a heterogeneous data processing network gateway | |
| US5881269A (en) | Simulation of multiple local area network clients on a single workstation | |
| US6553428B1 (en) | Distributed object instantiation of native objects in java | |
| US4914619A (en) | Apparatus and method for interconnecting an application of a transparent services access facility to remote source | |
| US5894557A (en) | Flexible point-to-point protocol framework | |
| Schmidt | A family of design patterns for applications-level gateways | |
| Braden | A server host system on the arpanet | |
| JPH10320220A (en) | Method and device for transferring describer | |
| JPH09265409A (en) | Dynamic execution unit management for high performance user level network protocol server system | |
| CN101089852B (en) | Method for support multi-language operation system | |
| WO2001086468A1 (en) | Internet-enabled embedded device | |
| Keller et al. | CCS resource management in networked HPC systems | |
| Oh et al. | CORBA based core middleware architecture supporting seamless interoperability between standard home network middlewares | |
| US6408329B1 (en) | Remote login | |
| CA2107298A1 (en) | Method and mechanism for allocating switched communications ports in a heterogenous data processing network gateway | |
| Mountzia et al. | Communication requirements and technologies for multi-agent management systems | |
| KR20020033219A (en) | Method for materializing connection-oriented socket interface | |
| Sommers et al. | Cluster-based computing with active, persistent objects on the web | |
| KR100344201B1 (en) | Tcp/ip connection device of banking system | |
| Ren | Communication Architecture Design and Case Study of Embedded Partition Real-Time Operating System | |
| Faro et al. | A multimicrocomputer-based structure for computer networking | |
| IM | management, device management, virtual file system management and other functions. Configurable components are components that provide specific functional requirements for different airborne software, mainly including C | |
| Buxton et al. | The ULTRIX implementation of DECnet/OSI |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |