US20010047392A1 - Multiplexing of clients and applications among multiple servers - Google Patents

Multiplexing of clients and applications among multiple servers Download PDF

Info

Publication number
US20010047392A1
US20010047392A1 US09394568 US39456899A US2001047392A1 US 20010047392 A1 US20010047392 A1 US 20010047392A1 US 09394568 US09394568 US 09394568 US 39456899 A US39456899 A US 39456899A US 2001047392 A1 US2001047392 A1 US 2001047392A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
job
child
server
step
session
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.)
Granted
Application number
US09394568
Other versions
US6345291B2 (en )
Inventor
Thomas Edwin Murphy Jr
Jeffrey Scott Stevens
Original Assignee
Thomas Edwin Murphy Jr
Jeffrey Scott Stevens
Priority date (The priority date 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 date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Queuing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/02Network-specific arrangements or communication protocols supporting networked applications involving the use of web-based technology, e.g. hyper text transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing
    • H04L67/1004Server selection in load balancing
    • H04L67/1008Server selection in load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing
    • H04L67/1004Server selection in load balancing
    • H04L67/1012Server selection in load balancing based on compliance of requirements or conditions with available server resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/14Network-specific arrangements or communication protocols supporting networked applications for session management
    • H04L67/142Network-specific arrangements or communication protocols supporting networked applications for session management provided for managing session state for stateless protocols; Signalling a session state; State transitions; Keeping-state mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/16Transmission control protocol/internet protocol [TCP/IP] or user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06047Protocols for client-server architecture
    • H04L2029/06054Access to distributed or replicated servers, e.g. using brokers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1002Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers, e.g. load balancing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/42Protocols for client-server architectures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/08Protocols for interworking or protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer, i.e. layer five
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32High level architectural aspects of 7-layer open systems interconnection [OSI] type protocol stacks
    • H04L69/322Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Aspects of intra-layer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer, i.e. layer seven

Abstract

In an Internet system having a plurality of applications, and a plurality of servers for attachment from a plurality of web browsers, a system supports connection oriented applications over a connectionless protocol. At least one of the servers is a master server work station gateway owning a well-known port, and the other servers are slave servers supporting established web browser-to-application state sessions. Dynamic session authentication checking is done by the server to prevent the occurrence of screen spoofing by providing authentication keys which are unique to each session and each panel.

Description

    BACKGROUND OF THE INVENTION
  • [0001]
    Internet workstations are connectionless-oriented socket clients or applications that connect to a server only long enough to retrieve an installment of data.
  • [0002]
    Once the data is retrieved, connectionless oriented socket applications generally disconnect until the next data transaction is initiated by the client. Connection oriented applications assume that the client maintains the connection to the server for the duration of the session. The client only disconnects when the session is being ended.
  • [0003]
    With connection-oriented applications, the identity and synchronization of both the client and server are known to both sides of the connection. Thus, it is taken for granted that the client is trusted and the data exchange is synchronized (in particular, the “current” or “active” application panel is known).
  • [0004]
    However, in connectionless-oriented applications, in which the Hypertext Transfer Protocol (HTTP) class of service belongs, this connection is not maintained, and thus the identity and synchronization of either the client or server, or both, may change unknown to the other side. This has the potential to result in “out-of-sync” data exchanges, and it is not known if the reconnecting client was the original session initiator. This could “break” an application or expose sensitive data to another, unauthorized client. Consequently, there is a need in the art to assure that once an application is started with a given web browser, another browser cannot come along and connect or “spoof” (that is, steal, or take over) that browsers connection and application.
  • [0005]
    The IBM 5250 datastream is a device specific datastream for an IBM AS/400 computer system. Such a device specific datastream may be a serial stream of data bytes in hexadecimal form. A Workstation Gateway (WSG), acting as a protocol converter, receives IBM 5250 datastreams from connection-oriented type applications that depend on a connected state of direct communication with the attached device. The WSG converts the native 5250 datastreams into an equivalent Hypertext Mark-up Language (HTML) document and delivers the document to the destination client host browser over a connectionless-oriented protocol, called Hypertext Transfer Protocol (HTTP).
  • [0006]
    The problem of job management is complicated by the fact that all browser-to-application sessions can only be initiated through the one WSG server that owns the socket with the “well-known” port defined for this service. Each session that is initiated must somehow be assigned to another WSG server by the one WSG server owning the “well-known” port.
  • [0007]
    It is an object therefore of the invention to provide an internet connection for a workstation gateway that supports connection-oriented type applications (can also be called “state” applications) over a connectionless-oriented (or “stateless”) type protocol.
  • [0008]
    It is a further object of the invention to provide a workstation gateway server that supports and connects/reconnects multiple applications and clients through a single server, which maintains the illusion of a connectionless-oriented environment to the browser and a connection-oriented appearance to the interactive application.
  • [0009]
    It is a further object of the invention to manage multiplexing of web browsers and applications through one or more workstation gateway servers, where each such server may handle one or more browser to application connections.
  • SUMMARY OF THE INVENTION
  • [0010]
    In accordance with this invention, in an internet system having a plurality of applications, and a plurality of servers for attachment from a plurality of web browsers, the system supports connection-oriented applications over a connectionless protocol. At least one of the servers is a master (parent) server Work Station Gateway owning a well-known port, and the other servers are slave (child) servers supporting established web browser to application state sessions.
  • [0011]
    In accordance with a further aspect of the invention, a method is provided for connecting a client to an application, comprising the steps of maintaining in a job available queue a plurality of identifiers of available child jobs; responsive to a request from a client to connect to an application, operating a server parent job to dequeue from said job available queue the identifier of a next available child job and dispatch said request to said available child job; and operating said available child job to establish a connectionless-oriented communications environment for said client and a virtual connection-oriented communications environment for said application.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0012]
    [0012]FIG. 1 shows multiplexing of web browsers and applications through multiple servers, where each server may handle one or more browser-to-application connections.
  • [0013]
    [0013]FIG. 2 shows a high level view of a 5250/HTML Workstation Gateway.
  • [0014]
    [0014]FIG. 3 shows a 5250/HTML Workstation Gateway job structure.
  • [0015]
    [0015]FIG. 4 is a diagram illustrating the format of a session connection HTML link.
  • [0016]
    [0016]FIG. 5 is a diagram illustrating the format of an established session HTML link.
  • [0017]
    [0017]FIG. 6 is a flow diagram of the start up program.
  • [0018]
    [0018]FIG. 7 is a flow diagram illustrating the method steps of the server parent job of FIG. 2.
  • [0019]
    [0019]FIGS. 8A and 8B are a flow diagram illustrating the method steps of the server child job 1 of FIG. 2.
  • [0020]
    [0020]FIGS. 9A and 9B are diagrammatic representations of two configurations of gateway/browser client systems.
  • DETAILED DESCRIPTION OF THE INVENTION
  • [0021]
    Referring to FIG. 1, a plurality of applications 100, 102, 104 at one or more system nodes, such as may be provided by one or more IBM AS/400 computing systems, are accessed by clients using web browsers 120, 122, 124 through work station gateway servers 110, 112, 114. As is represented by lines 131, 137, gateway server 110 connects browser 124 to application 104, and as is represented by lines 131, 135, gateway server 112 connects browsers 120, 122 to applications 100, 102.
  • [0022]
    Referring further to FIG. 1, in one specific embodiment of the invention, 5250 datastream 133 is a device specific datastream for an IBM AS/400 computer system. Such a device specific datastream may be a serial stream of data bytes in hexadecimal form. A Workstation Gateway (WSG) 110, acting as a protocol converter, receives IBM 5250 datastreams from connection-oriented type applications 104 that depend on a connected state of direct communication with the attached device. WSG 110 converts the native 5250 datastreams on line 133 into an equivalent Hypertext Mark-up Language (HTML) document and delivers the document, as is represented by line 137, to the destination client web browser 124 over a connectionless-oriented protocol, called Hypertext Transfer Protocol (HTTP).
  • [0023]
    Herein, a socket is a unique host identifier created by the concatenation of a port identifier with a transmission control protocol/Internet protocol (TCP/IP) address. A socket address is a data structure that uniquely identifies a specific communications end point; it consists of a port number and network address; and it also specifies the protocol family. See, G. McDaniel, Ed., IBM Dictionary of Computing, McGraw-Hill, Inc., page 632, (1994). Sockets, and socket programming, are well known in the art. See, for example, W. Richard Stevens, UNIX Network Programming, Prentice-Hall (1990), Chapter 6, at pages 260, 261; and, IBM, IBM AS/400 System API Reference, Vol. 3, Version 3, IBM Publication SC41-3801-00, Chapter 65, pages 65-1 through 65-74 (Sept. 1994).
  • [0024]
    As used in connection with this preferred embodiment of the invention, the following terms have the meanings given: Port: sockets parlance for the “number” of a socket. All sockets are identified uniquely by their address and port. Two connected sockets are uniquely identified by the four-tuple of the address and port of each socket endpoint.
  • [0025]
    Socket: a TCP/IP communications protocol entity.
  • [0026]
    Job: an AS/400 batch job.
  • [0027]
    Exit: to end an AS/400 batch job.
  • [0028]
    Session: each AS/400 batch job manages “n” sessions. Each browser client gets allocated one session when a request is made.
  • [0029]
    Link: Uniform Resource Locator (URL), or hypertext link.
  • [0030]
    Form: term for a special kind of HTML document.
  • [0031]
    String: alphanumeric set of characters.
  • [0032]
    Session string: unique string assigned to identify a session.
  • [0033]
    Signature: same as session string.
  • [0034]
    Connect id string: same as session string.
  • [0035]
    Panel: a display panel, application display panel.
  • [0036]
    Identifier: a portion (sub-string) of the session string.
  • [0037]
    Key: a portion (sub-string) of the session string.
  • [0038]
    Socket programming is described in IBM, IBM AS/400 System API Reference, Vol. 3, Version 3, IBM Publication SC41-3801-00, Chapter 65, pages 65-1 through 65-74 (Sept. 1994), the teachings of which are incorporated herein by reference. In that reference, and in the description which follows of a preferred embodiment of the invention, reference is made to the following socket functions.
  • [0039]
    accept( )
  • [0040]
    Wait for connection request and make connection
  • [0041]
    The accept( ) function is used to wait for connection requests. Accept( ) takes the first connection request on the queue of pending connection requests and creates a new socket to service the connection request. Accept( ) is used with connection-oriented socket types.
  • [0042]
    bind( )
  • [0043]
    Set a local address for socket
  • [0044]
    The bind( ) function is used to associate a local address to a socket.
  • [0045]
    close( )
  • [0046]
    End socket connection
  • [0047]
    The close( ) function is used to close a file or socket descriptor.
  • [0048]
    connect( )
  • [0049]
    Establish connection or destination address
  • [0050]
    The connect( ) function is used to establish a connection on a connection-oriented socket or establish the destination address on a connectionless socket.
  • [0051]
    getservbyname( )
  • [0052]
    Get port number for service name
  • [0053]
    The getservbyname( ) function is used to retrieve information about services (the protocol being used by the service and the port number assigned for the service). The information is retrieved from the service database file.
  • [0054]
    getsockname( )
  • [0055]
    Retrieve local address of socket
  • [0056]
    The getsockname( ) function is used to retrieve the local address associated with the socket.
  • [0057]
    givedescriptor( )
  • [0058]
    Pass descriptor access to another job
  • [0059]
    The givedescriptor( ) function is used to pass a descriptor from one OS/400 job to another OS/400 job.
  • [0060]
    ioctl( )
  • [0061]
    Change descriptor attributes
  • [0062]
    The ioctl( ) function is used to obtain or change the attributes of a file or socket descriptor.
  • [0063]
    listen( )
  • [0064]
    Invite incoming connections requests
  • [0065]
    The listen( ) function is used to indicate a willingness to accept incoming connection requests. If a listen( ) is not done, incoming connections are refused.
  • [0066]
    read( )
  • [0067]
    Receive data
  • [0068]
    The read( ) function is used to receive data from a file or a socket.
  • [0069]
    select( )
  • [0070]
    Wait for events on multiple sockets
  • [0071]
    The select( ) function is used to enable an application to multiplex I/O. By using select( ), an application with multiple interactive I/O sources avoids blocking on one I/O stream while the other stream is ready. Thus, for example, an application that receives inputs from two distinct communication endpoints (using sockets) can use select( ) to sleep until input is available from either of the sources. When input is available, the application wakes up and receives an indication as to which descriptor is ready for reading.
  • [0072]
    The application identifies descriptors to be checked for read, write and exception status and specifies a timeout value. If any of the specified descriptors is ready for the specified event (read, write or exception), select( ) returns indicating which descriptors are ready. Otherwise, the process waits until one of the specified events occur or the wait times out. setsockopt( ) Set socket options
  • [0073]
    The setsockopt( ) function is used to set socket options.
  • [0074]
    socket( )
  • [0075]
    Create socket
  • [0076]
    The socket( ) function is used to create an end point for communications. The end point is represented by the socket descriptor returned by the socket( ) function. takedescriptor( )
  • [0077]
    Receive socket access from another job
  • [0078]
    The takedescriptor( ) function is used to obtain a descriptor in one OS/400 job which was passed from another OS/400 job by a givedescriptor( ).
  • [0079]
    write( )
  • [0080]
    Send data
  • [0081]
    The write( ) function is used to write data to a file or socket descriptor.
  • [0082]
    Referring to FIG. 2, as will be more fully explained hereafter, one server parent (also referred to as a master server) job 200 and two server child (also referred to as slave server) jobs 202 and 204 are illustrated, along with job available queue 206. (The process implemented by server parent job 200 is further described hereafter in connection with FIG. 7, and that by server child job 202 hereafter in connection with FIGS. 8A and 8B.)
  • [0083]
    Server parent job 200 executes the following process: in step, 310, job 200 waits for connect( ), which when received, in step 312, executes accept( ) to accept the connect request. In response thereto, in step 314, job 200 dequeues a JOBID from available queue 206, as is represented by line 345; in step 316 sends “wakeup” connect( ) to the appropriate server child job 202 or 204 (depending on which jobid it dequeued in step 314); and issues givedescriptor(jobid) to that job 202 or 204. Thereupon, in step 320, job 200 executes close( ) accepted socket, and asks in step 322 if the number remaining in queue 206 is less than or equal a predetermined threshold—if not, as is represented by line 323, loops back to step 310; and if so, in step 324 issues SBMJOB, an AS/400 command meaning submit job, in this case to start another server child job.
  • [0084]
    Referring further to FIG. 2, server child job 202 executes the following process. Server child job 204 executes a similar process. Server child job 202, upon being started, as is represented by line 341, initializes by enqueueing n=20 jobids 336-340 on queue 206, as is represented by line 341, and in step 212 sets n=20 and active=0. (The value “n” is obtained from configuration file 438, FIG. 3, which represents all server run time attributes that are settable or configurable by the customer and stored on DASD.) Server child job 202 waits in step 216 for wakeup connect( ) directed to it from step 316 of server parent job 200. Upon receiving “wakeup”, server child job 202 executes steps 216, 218 and 220 to takedescriptor( ), set n=n−1 and active=active +1, and add socket to set, respectively. In step 222, server child job 202 blocks on select( ) timer, and upon timeout, in step 224, determines if there are active sockets in set. If so, in step 226, server child job 202 causes execution of the appropriate read( ) or write( ) data commands. (Thus, step 222 blocks two ways on select( ): true blocking if all pending client requests took the yes branch off step 227, and temporary blocking (via timeout) if any clients are still waiting for a yes branch off step 225 (see FIG. 8A.)) (Looking ahead to FIG. 3, the structure provided for implementing this step 226 is illustrated within block 500.) In step 227, server child job 202 determines if the session is closed, and if so, as is represented by line 349, enqueues a jobid to queue 206. In step 228, job 202 determines if the number of jobid's enqueued in queue 206 is equal to or less than some predetermined threshold value and, if so, in step 230, calls SBMJOB to initiate another server job, in this example, server child job 2, and as is represented by line 229, loops back to step 214 to await the next “wakeup” connect( ) from server parent job 200.
  • [0085]
    Server child job 204 executes, in steps 240-258, 260, and on lines 343, 347 and 259 functions identical to those described above with respect to server child job 202, steps 210-228, 230, and lines 341, 229 and 349, respectively. It also places jobs 330-334 on queue 206, as previously described with respect to jobs 336-340.
  • [0086]
    Referring to FIG. 3, the system (program and hardware) structure of the preferred embodiment of the invention is shown for implementing server child jobs 202 (server 110 of FIG. 1) and 204 (server 112 of FIG. 1) in, for example, workstation gateway server 110. Implementation of server parent job 200 is similar, differing in that the structure illustrated within block 500 is not required, as will become apparent hereafter.
  • [0087]
    As is represented by lines 501, 503, application program (APP) 410 (one of applications 100-104, FIG. 1) interfaces to user interface manager (UIM) 412, which in turn interfaces, as is represented by lines 505, 507, with workstation functional manager (FM) 414. Workstation FM 414 communicates, as is represented by request I/O (REQIO) OUT line 509 and IN line 511, across machine interface (MI) 559 with virtual terminal manager 416. Virtual terminal manager functional manager 436, a superset of virtual terminal manager 416 with controlling Extended Program Facility (XPF) code, communicates across MI 559 with virtual terminal manager 416 via OUT line 513 and IN line 515, by executing the AS/400 internal command: request path operation (REQPO's). (In a preferred embodiment, VTAP I/F 426 does all the interfacing with XPF, and block 436 is merely a logical entity shown for clarity.)
  • [0088]
    HTTP server 502 includes HTTP workstation server 446, including integrated language environment (ILE-C), an AS/400 facility for C language sockets programs, and accesses files 438, 440, 442 and 444. HTTP workstation server 446 interfaces with sockets block 448 as represented by lines 551 and 553, and with configuration file 438 (via change HTTP attributes commands CHGHTTPA, line 543), integrated file system (IFS) 440 (line 545), shared folders system 442 (line 547) and database 444 (line 549). Sockets block 448 communicates across machine interface (MI) 559 with TCP/IP network 450, as is represented by lines 555 and 557. Integrated file System (IFS) file 440, shared folders (SF) file 442, and data base (DB) file 444 contain server run time attributes, each being accessible by HTTP server 446.
  • [0089]
    Application program exit QAAP0100 block 418 interfaces, as is represented by lines 517 and 519, with workstation gateway 420, which includes standard intermediate representation (SIR)/HTML translator block 422, virtual terminal application program interface (VTAPI) session manager 424, and VTAPI interface (I/F) ILE-C block 426. As is represented by line 413, virtual terminal queue 417 is maintained by virtual terminal manager 416 and, as is represented by line 415, is checked by gateway 420, as will be described hereafter. Workstation Gateway server 420 in FIG. 3 is, for example, Workstation Gateway server 110 of FIG. 1; it is a child job—the parent job being a special case, doing only dispatching to child jobs, and is not seen in FIG. 1. APP PROG EXIT block 418 represents a customer developed user exit program, giving the customer the ability to dictate to the workstation gateway the parameters to use to sign-on to the AS/400 system. This ability is useful for security purposes, in order to avoid having passwords sent over exposed networks, and for automatically launching a customer application.
  • [0090]
    Gateway 420 accesses configuration file 438 via change workstation gateway attributes (CHGWSGA) as represented by line 537, and with sockets block 448, as represented by lines 539, 541. In this embodiment, gateway 420 communicates with virtual terminal manager functional manager 436 via initiate (I) block 428 as represented by OPEN lines 521, 529; via read (R) block 430, as represented by READ lines 523, 525 and 531; via write (W) block 432 as represented by WRITE lines 527, 533; and via terminate (T) block 434 as represented by CLOSE lines 528 and 535. Blocks 428-434 represent the virtual terminal (VT) application program interfaces (API) used: open, read, write, and close, respectively. SIR/HTML translator block 422 calls SAC to build screen objects, translate them to HTML form and send them to client browser, as will described hereafter in connection with FIGS. 7, 8A and 8B, VTAPI I/F block 426 performs method steps 226, 221, 225, 233, 227 and 236; all of the other steps shown are performed in VTAPI session manager 424.
  • [0091]
    Referring now to FIGS. 1-3, in operation, in accordance with this invention, a workstation gateway 110 is a TCP/IP application that services requests from HTTP clients using the HTTP request/response protocol. These requests arrive in a variety of ways, for example: directly from a client browser 124, as shown in FIG. 1, to the listening port (for example, on line 137, 557), or by redirection of any HTTP connect request that redirects the workstation gateway keyboard to a local or remote AS/400.
  • [0092]
    Referring to FIGS. 9A and 9B, this redirection is illustrated with respect to local AS/400 system 140 workstation gateway 141 and personal computer 142 browser client 143. In FIG. 9A, browser client 143 sends a direct request to gateway 141. In FIG. 9B, direct request 147 is sent to AS/400 system 144, which includes HTTP 145, which redirects the request as represented by line 148 to gateway 141 at local AS/400 system 140. Clients 143 may be redirected to the workstation gateway server 141 by an HTTP server 145, if that HTTP server 145 is configured to do so. Since an HTTP server is not required to be running on the same AS/400 system as the WSG server, the request may actually have been sent to a “remote” AS/400 system 144 before being redirected to the “local” AS/400 system 140. In this respect, the term “local” means the AS/400 system upon which the work station server is running. In this embodiment, the AS/400 system is represented by blocks 100-114 in FIG. 1, and by everything in FIG. 3 excepting block 450.
  • [0093]
    Once the initial connect request is received from a client 120, that client is considered “active”, and all future connection requests for that client 124 occur over an arbitrary port number. This port number is embedded into all HTML links and forms sent to client 124 (line 137), starting with the initial panel.
  • [0094]
    Client 124 remains active until the session is signed off (step 227, 257) or the inactivity timeout limit is reached.
  • [0095]
    In accordance with this embodiment of the invention, workstation gateway 110 maintains the illusion that browser 124 is logically connected to AS/400 application 104 even though every transaction between the browser 124 and server 110 disconnects.
  • [0096]
    Server 110 maintains the virtual terminal connection indefinitely or until browser 124 logs off (step 257) or an inactivity timeout value is exceeded, as is represented by process steps 227 and 257 (FIG. 2), meaning session closed by browser client or timed out.
  • 5250/HTML Workstation Gateway Connect Uniform Resource Indicator (URI) Interpretation
  • [0097]
    A preferred embodiment of the workstation gateway server 110 of this invention is provided by the IBM 5250/HTML Workstation Gateway. In accordance with this embodiment, the following described connection URI parameters are provided.
  • Connection URI Parameters
  • [0098]
    Referring to FIG. 4, the session connection syntax to initiate a new 5250/HTML Workstation Gateway 110 session with a web browser client 124 has the form:
  • http://xxx.xxx.xxx.xxx:5061/WSG/QAPP0100APP0100?any_oper_info
  • [0099]
    This connect identifier string 600 is broken down as set forth in Table 1.
    TABLE 1
    INITIATE CONNECTION URI IDENTIFIER STRING
    URI KEYWORD DESCRIPTION
    http://xxx.xxx.xxxxx.xxx:5061 The 5250/HTML Workstation
    Gateway HTTP hyperlink
    608, 610. The port number
    610 allocated for the
    5250/HTML Workstation
    Gateway server 110 is
    defined in the TCP/IP
    Services Database 444,
    and is assumed to be
    5061, for this example.
    /WSG The 5250/HTML Workstation
    Gateway program request
    keyword 612. This key-
    word indicates the re-
    quest is for the 5250/HT-
    ML Workstation Gateway
    420 and not HTTP Web
    Server 446.
    /QAPP0100? The 5250/HTML Workstation
    Gateway exit point
    QIBM_QTMT_WSG format
    QAPP0100 user exit
    request 614 indicator
    (block 418).
    any_oper_info This is any validation
    information 616 that the
    client would like to send
    to the User Exit program
    418 (if it is registered)
    for exit point QAPP0100.
    This portion is optional.
  • 5250/HTML Workstation Gateway Session URI Interpretation Established Session URI Parameters
  • [0100]
    Referring to FIG. 5, the session identifier string 602 for an established 5250/HTML Workstation Gateway 110 session with a Web Browser client 124 has the sample form:
  • http://xxx.xxx.xxx.xxx:1117/WSG/067486/QTMTWSG/QTWSG00712/01C863B24F0CE391/1B145952
  • [0101]
    Session identifier string 602 is broken down as shown in Table 2:
    TABLE 2
    ESTABLISHED CONNECTION URI IDENTIFIER STRING
    URI Keyword Description
    http://xxx.xxx.xxx.xxx:1117 The 5250/HTML Workstation
    Gateway HTTP hyperlink
    618, 620. The port number
    620 allocated for this
    client is 1117.
    /WSG The 5250/HTML Workstation
    Gateway request keyword
    622. This keyword
    indicates the request is
    for the 5250/HTML
    Workstation Gateway 420 and
    not HTTP Web Server 446.
    /067486/QTMTWSG/QTWSG0 The 5250/HTML Workstation
    0712 Gateway virtual terminal
    session 624 that was
    allocated for this client
    124.
    /01C863B24FOCE391 The 5250/HTML Workstation
    Gateway session identifier
    signature 626.
    /1B145952 The 5250/HTML Workstation
    Gateway active panel
    signature 628.
  • Spoofing of Session Panels
  • [0102]
    Once an application 104 is started with a given web browser 124, another browser 120, 122 cannot come along and connect or spoof (that is, steal, or take over) that browsers connection 133, 137 and application 104.
  • [0103]
    Workstation gateway server 110 acts on browser 124 requests in accordance with the content of the request-URI 600, 602 from the request line 557. However, aside from the initial session request 600, it will only act on those requests 602 that submit the proper authentication string 606 via the HTML “hidden” forms input field, to identify the user as the session initiator. Authentication string 606 identifies both the session initiator 626 and the currently active panel 628.
  • [0104]
    The session 626 and panel 628 signatures for a browser client 124 has the form described previously. Signatures are part of the entire session identifier string 602 (also called the connect identifier string). String 600 is a request for a new WSG session to be assigned to a browser client, and has no signatures in it. Session identifier 626 is generated by a 32-bit CRC hashing algorithm of the session string 624 and initiation time stamp 630. These strings are combined at session initiation time to create a session identifier string 626, in response to a browser client requesting a gateway session. This is generated only once—at session initiation time.
  • [0105]
    For example, the string “Wed Jul 5 09 :58:23 1995” and string 624 “1067486/QTMTWSG/QTWSG00712” both get hashed together into a session identifier signature 626 (2 different keys concatenated together) as demonstrated in the prototype code debug messages of Table 3:
    TABLE 3
    vt_open: Hash pszTime for 1st half key value
    vt_open: pszTime: >Wed Jul 5 09:58:23 1995<
    CalcCRC32: CRC Seed: >00000000<
    CalcCRC32: CRC Value: >8D3FAFE6<
    vt_open: Hash VT_Job for 2nd half key value
    vt_open: VT_Job: >067486/QTMTWSG/QTWSG00712<
    CalcCRC32: CRC Seed: >00000000<
    CalcCRC32: CRC Value: >81CD39DF<
    vt_open: Using VT_Key >8D3FAFE681CD39DF<
  • [0106]
    Likewise, panel identifier signature 628 (1 key) for browser client 124 is generated by a 32-bit CRC hashing algorithm of the screen panel buffer (not shown). This is done for EVERY panel that goes out, so every panel has a different panel key 628. Thus, a panel key is a portion (sub-string) of the session identifier string, generated from hashing the panel into a key. (The terms “key” and “signature” are used interchangeably.)
  • [0107]
    Cyclic redundance checking (CRC) hashing technology is well known to those skilled in the art. See, for example, Terry Ritter, “The Great CRC Mystery”, in Dr. Dobb's Journal, February 1986, pages 26-34.
  • [0108]
    In accordance with the invention, dynamic session authentication checking is done by the server 110-114 to insure screen spoofing does not occur. Since authentication keys are unique to each session and each panel, spoofing can only occur via real-time interception of the keys. This provides “pretty good” security, because keys are hashed using time stamps, meaning keys cannot be re-used. The hashing algorithm has odds of getting duplicate keys of “1 in 4 billion”. As the server uses 3 keys, the odds against spoofing are fairly high. As is illustrated in FIG. 5, field 626 is two keys concatenanted together: the first key is from hashing the time stamp, and the second key is from hashing string 624. The third key is string 628. Thus, field 606 represents the three keys all concatenated together. This time stamp is created and used only once, for each web browser client that requests a session. This means each session has a single time stamp associated with it, intended to defeat attempts to spoof a session because the time stamp changes each time a new session is requested. This time stamp does not change with each panel; rather, the panel key tracks panel changes as there may be a series of panels within a session. The real keys exist in the session identifier signature 626, as the panel signature 628 is mainly to keep the client Web Browser 124 “tree” in sync with the active panel.
  • [0109]
    In accordance with this preferred embodiment based on the IBM 5250/HTML workstation gateway, server 110 is started via the AS/400 STRTCPSVR command or it is started via AUTOSTART option of the STRTCP command. These and other AS/400 control language (CL) commands herein referenced are described in IBM publications SC21-9775-02, SC21-9776-02, SC21-9777-02, SC21-9778-02, SC21-9779-02, AS/400 Prog: CL Ref, volumes 1-5, respectively.
  • [0110]
    Referring to FIGS. 2 and 3, the workstation gateway server is organized into:
  • [0111]
    1) A single parent (or master) job 200 that listens for and accepts connection requests, as may be received on line 557, from HTTP browser clients 124 on network 450. The port (Table 1, port 5061) used by 5250/HTML Workstation Gateway 420 is different from the HTTP server 446, because the 5250/HTML Workstation Gateway is a new type of server for which there is no “well-known” port. Parent job 200 has only one function—to hand off connection requests to child jobs 202, 204. Parent job 200 is the first job that can successfully do a bind( ) socket call to the configured port. Socket calls are done by blocks 424 and 420. Sockets programming requires that only one job can bind successfully to the configured port. A configured port is the port on which requests are detected, which port can be changed from a default value through the use of the WRKSRVTBLE, ADDSRVTBLE, and RMVSRVTBLE CL commands. This allows customers to change the socket port value listened to, and is determined in step 306 (FIG. 7.)
  • [0112]
    2) One or more child (or slave) jobs 202, 204, each of which has enqueued its identifier on the job available queue 206. A child job 202 performs the actual work to satisfy the client 124 connect request. This is represented by blocks 428-434 and lines 521-528 in FIG. 3. Child jobs 202, 204 are those jobs that receive an address-already-in-use (EADDINUSE) socket error when attempting to bind( ) to the configured port. In this manner it is determined that a parent is already running, and that this particular batch job should be run as a child job. There are two types of child jobs:
  • [0113]
    a) A free child job 330-340 is a job that is not currently processing a client session. Free child jobs DO have their identifier on the job available queue 206.
  • [0114]
    b) An active child job (not 330-340) is a job that is currently processing (steps 226, 256) a client session that has not yet signed off or timed out (steps 227, 257). Active child jobs do NOT have their identifier on the job available queue 206.
  • [0115]
    3) A job available queue 206 which provides the parent job 200 a means to identify free child 202, 204 jobs 330-340 to handle new connect requests, via a “wakeup” socket connect( ) request 316, 214, 244. Since a child job 202, 204 may be busy processing other sessions, the “wakeup” scheme allows each child job to know the parent 200 is attempting to dispatch a new session to the child, and therefore the child job should block, step 252, 222, on the takedescriptor( ) socket call. This insures a child job will not block unless the parent job has already performed a givedescriptor( ) call 218 to it. (Some socket calls block further server activity until interrupted. This invention avoids such indeterminate blocking.)
  • [0116]
    Since only one WSG server 110-114 can own the “well-known” port, WSG servers 200, 202, 204, 110-114 essentially function in either one of two modes: they are either the master server, aka server parent, 200 (of which there can only be one), or they are slave servers, aka server children, 202, 204. (This reference to a “well-known” port is in anticipation that it will become such as the product embodiment of this invention gains wide-spread usage. It is not yet truly well-known as that term is generally understood.)
  • [0117]
    Master server 200 owns the “well-known” port, all other servers 202, 204 are slave servers and perform the actual work supporting established browser-to-application, 124 to 104, or 450 to 410, state sessions. Master server 200 assigns new sessions amongst the slave servers 202, 204 and does no other work. (Thus, block 500, FIG. 3, does not exist in an instantiation of master server 200.)
  • [0118]
    Each slave server 112 (202, 204) must notify (step 210, 240) master server 110 (200) how many new sessions it can support, before all of its slots are used up with established browser (120, 122) to application (100, 102) sessions. Whenever an established browser-to-application session is ended, slave 202, 204 must notify (step 231, 261) the master 200 it has an additional slot 330-340 available.
  • [0119]
    Slave and master servers communicate through a common queue object 206, where each slave job 202, 204 enqueues (step 210, 240) one or more entries 330-340 at startup time that indicates “this slot is available for a new session”. A job is an AS/400 batch job, in this embodiment, and a slot is the same thing as a session, in that each batch job manages several sessions (or slots.)
  • [0120]
    As session requests arrive (step 310, line 557) at master server 200, the master dequeues (step 314) an entry (say, 330), and gives (steps 316, 318, 244, 246) the request to the slave server 204 whose entry 330 was dequeued. This assignment continues, each slave server 202, 204 managing one or more established sessions until all of its sessions (that is, slots) are full (active=n) or one of the sessions ends (step 227, 257). If a session ends, slave 202, 204 enqueues a single entry (step 231, 261) to indicate a slot has been made available. In this sense, an entry is a slot and is also known as a session.
  • [0121]
    In accordanced with this specific embodiment, the number of slots (n) each slave server supports is called its multiplexing value, and this value can be configured (in configuration file 438) by the customer to achieve the best performance on his AS/400 system. Since each WSG server 110-114, 200-204, 420 running on an AS/400 runs as a batch job in a sub-system, management of the number of jobs running is critical to performance. Because there is significant overhead associated with each batch job 330-340, using a single batch job to support one browser 124 to application 104 session wastes system resources and degrades performance.
  • [0122]
    To support even better performance, both master server 200 and slave servers 202, 204 are aware of a “floor” or “backlog” of available slots/sessions 330-340 that must be maintained. If the total number of available slots 330-340 from all the slave servers drops below this value (steps 228, 250, 322), then another slave server 112-114 is started (steps 230, 260, 324). This “pre-starting” of slave servers 112-114 helps to boost performance at times of peak demand, which otherwise would introduce a latency delay while a server initializes. Since each slave server 202, 204 is aware of a “floor” or “backlog”, they can compare the total number of available slots 330-340 from all the slave jobs against this floor value, and make intelligent decisions on whether the available number of slots is too high, and terminate slave servers, or jobs, to reduce this number back down to the floor level.
  • [0123]
    A Cyclic Redundancy Check (CRC) hashing mechanism is used to maintain both a client 120-124, 450 identifier 626 and a data identifier 628, which is exchanged on each data transaction (steps 226, 256, block 500). This provides authentication and synchronization information from the client 120-124 to the server application 110-114, 200-204. Server application 112 can then allow controlled data exchange among multiple clients 120-122 that is transparent to and independent of other clients and their respective applications 100-102.
  • [0124]
    The CRC hashing results in a string of invariant EBCDIC hexadecimal characters (0-9,A-F) as output, which is then converted to ASCII and sent to the client 124, etc. Using invariant characters allows this solution to be leveraged across most national languages.
  • [0125]
    Referring to FIG. 7, the 5250/HTML Workstation Gateway Startup Job, or program, 300 of this specific preferred embodiment is executed by block 420.
  • Start-up Responsibilities
  • [0126]
    Startup program 300 has the following responsibilities:
  • [0127]
    1. In step 301, providing a job available queue (*USRQ) 206.
  • [0128]
    2. In step 302, providing a virtual terminal queue (*DTAQ).
  • [0129]
    3. In steps 304 and 305, respectively, starting the parent 200 and first child 202 jobs via SBMJOB.
  • [0130]
    Step 301, providing a job available queue 206: start-up program 300 creates the “job available queue” 206, on which free child jobs 202, 204 will register themselves. HTML Workstation Gateway parent job 200 uses this queue 206 to find a child job 202, 204 that is available to handle a connection from a new browser client 120-124, 450. The name of this queue 206 is QWSG/QTMTJOBQ, and it is a FIFO queue. Queue 206 is FIFO type in order to allow child jobs 202, 204 to “drain” their entries 330-340 off the queue when the child job ends.
  • [0131]
    Step 302, providing a virtual terminal queue: parent job 200 requires a “virtual terminal queue” 417, which is how the virtual terminal notifies child jobs 202, 204 that the AS/400 has 5250 datastreams pending. The name of this queue is QWSG/QTMTVTQ, and it is a keyed queue. The key is the job identifier.
  • [0132]
    Steps 304 and 305, starting the parent and child jobs: once the queues are created and initialized, startup program (QTMTJOBS *PGM) 300 starts a parent 200 and an appropriate number of child jobs 202, 204 based on the selected multiplexing value. Parent job 200 binds to the configured port and listens for connect requests (step 310). Child job 202 reads configuration file 438 to determine the level of multiplexing sessions of connect requests that is to be done. Startup program 300 starts both parent 200 and child jobs 202, 204 using the SBMJOB CL command.
  • Parent 200 Responsibilities
  • [0133]
    Referring to FIG. 7, 5250/HTML Workstation Gateway parent job 200 has the following responsibilities:
  • [0134]
    1. In step 310, listening on the configured port (port extracted from services database 438).
  • [0135]
    2. In step 314, identifying the next available child 202, 204.
  • [0136]
    3. In steps 316 and 318, dispatching the next available child.
  • [0137]
    4. In step 324, starting additional child jobs 202, 204 to handle high levels of connect requests or to replace jobs that may have terminated unexpectedly.
  • [0138]
    (The socket programming calls and instructions referred to in the following description are further described in IBM AS/400 System API Reference, Vol. 3, Version 3, Sept. 1994, IBM Publication SC41-3801-00, pages 65-1 through 65-74. The server parent job instantiation is similar to that for the server child job set forth in FIG. 3, except that the parent job instantiation does not require the structure of block 500. Consequently, where appropriate in the following description, reference may be made to the structural elements of FIG. 3 as though they formed a server parent 200.)
  • [0139]
    Step 310, listening on the configured port. Parent job 200 monitors the configured port for connect requests from “browser” clients (such as browsers 120-124 on TCP/IP network 450) via the accept( ) socket call (on line 539). In steps 307 through 311 and 310, server 200 sets up (that is, binds) the configured port socket 448, as is described hereafter.
  • [0140]
    In step 306, parent job 200 determines the configured port to monitor by using the getservbyname( ) socket call. The getservbyname( ) call retrieves information about services listed in the service database file 444, which represents the WRKSRVTBLE repository.
  • [0141]
    In step 307, server 200 obtains a socket descriptor using the socket( ) API for the AF_INET address family, the SOCK_STREAM type, and the IPPROTO_TCP protocol.
  • [0142]
    In step 308, server 200 sets the socket to blocking type using the FIONBIO option of the ioctl( ) socket call.
  • [0143]
    In step 309, server 200 enables recovery (in case of errors or problems) of the bound port from ½ closed state by setting the socket descriptor option SO_REUSEADDR using the setsockopt( ) socket call.
  • [0144]
    In step 311, server 200 binds the descriptor to the configured port using the bind( ) socket call.
  • [0145]
    In step 310, server 200 states the willingness to accept connections using the listen( ) socket call.
  • [0146]
    The service name for 5250/HTML Workstation Gateway is ‘wsg’ and the protocol is TCP. Browser clients 120-124 are connectionless oriented, stateless communications.
  • [0147]
    Identifying the next available child: Referring further to FIG. 7, identifying the next available child proceeds as follows. As connection requests arrive (step 310, lines 557, 539) on the configured port, in step 312, parent 200 unblocks from the accept( ) call and in step 313 obtains a second socket descriptor for handling the “wakeup” connection. Once the accept( ) completes (step 312), in step 314 parent job 200 attempts to dequeue a free child job identifier 340. The dequeued element 330 is the job identifier of the free child job, say 202, and the allocated port number for that child job 202. There is one port for each session/slot as represented by blocks 336-340 of queue object 206. The allocated port number is the port on which that child job 202 is blocked on select( ) waiting (step 214) to accept connect requests.
  • [0148]
    Dispatching the next available child: Once parent 200 has identified a free child job 340, in step 316 parent 200 dispatches that job 340 by sending (step 316) a “wakeup” signal by performing a socket connect( ) request to a free child job 202. Parent job 200 reads the dequeued element off queue 206. If an entry from 330-334 was dequeued, then parent dispatches child job 204. If an entry from 336-340 was dequeued, parent 200 dispatches child job 202. Parent job 200 READS the entry information, so it knows which child job 202, 204 to dispatch.
  • [0149]
    Any child job 202 that is free will still be listening (step 214) on all the ports allocated to it, and the connect( ) request from parent job 200 in step 316 makes the child unblock in step 222 from the select( ) socket call and block on a takedescriptor( ) call. Once the child job gets the “wakeup” signal in step 214, in step 318 parent job 200 performs a givedescriptor( ) socket call. The sockets givedescriptor( ) passes a descriptor, that is, socket, for the connection to the targeted child job 202. A queue entry 330-340 on queue 206 identifies a socket in a particular child job; that is, a child job and a socket within that child job—and this is obtained in step 307. Since givedescriptor( ) is a non-blocking socket call, parent 200 need not wait for the corresponding takedescriptor( ) call to complete before being allowed to continue. Consequently, in step 320, server parent job 200 executes close( ) to close the accepted socket.
  • [0150]
    In steps 316, 318, after passing the connection to child job 202, in step 310 parent 200 resumes monitoring its listening socket 448 for incoming connect requests from browser clients 120-124 on, in this embodiment, TCP/IP network 450. This completes the parent 200 side of the “handoff”.
  • [0151]
    Starting additional server child jobs: Referring further to FIG. 7, parent server job 200 starts additional 5250 server child jobs 204, etc., as follows. Preliminary to step 322, parent job 200 monitors the job available queue 206 and extracts the number of entries 330-340 stacked on the queue (#QUEUED). When queue 206 is close to empty (step 322 evaluates true), in step 324, parent 200 attempts to “prestart” another child job 204 to handle additional connect requests, in order to reduce any latency time associated with SBMJOB startup.
  • Child Job 202 Responsibilities
  • [0152]
    Referring now to FIGS. 8A and 8B, 5250/HTML Workstation Gateway Child Job 202 (as also the other server child jobs 204, etc.) has the following responsibilities:
  • [0153]
    1. Register for new work on the job available queue 206 (step 210).
  • [0154]
    2. Listen on all active ports (step 213).
  • [0155]
    3. Open/Write (step 226) to the AS/400 virtual terminal session 500.
  • [0156]
    4. Read (also step 226) from the AS/400 virtual terminal session 500.
  • [0157]
    5. Write (step 234) to the client session 120-124, 450.
  • [0158]
    6. Log the request/response (step 226).
  • [0159]
    7. Monitor and close (steps 235-238) inactive clients 120-124, 450.
  • [0160]
    8. Re-register (step 231) on queue 206 for new work.
  • [0161]
    Step 210, register for new work on the job available queue 206. In step 210, child job 202 registers itself as ready for work by enqueueing its job identifier and allocated port number on the job available queue 206. In steps 210, 212, child job 202 stacks n copies 336-340 of its job identifier on the queue—where n is the configured level (from configuration file 438, step 208) of multiplexing to be performed.
  • [0162]
    Step 231, re-register available sessions. As sessions timeout (step 235) or log off (step 238), in step 231 child job 202 re-registers its available sessions by restacking the job identifier to available queue 206.
  • [0163]
    Step 213, listen on all active ports (a collection of specific sockets within a child job). Up to n connections can be active in child job 202, meaning the child can be listening (as is also represented by line 557, FIG. 3), in step 213 on up to n different ports for connect requests.
  • [0164]
    Steps 216, 226 accept and reply. If any port shows a connect request is pending (step 214 evaluates true), in step 216 child 202 accepts, and in step 226 processes and replies to the client connect request.
  • [0165]
    Step 215, authenticate session. Between steps 224 and 226 (and, similarly, between steps 254 and 256, FIG. 2), session authentication checking occurs. If the authentication check was good (OK), step 226 occurs; if not (NOT OK), step 226 is skipped. All active ports are checked on every pass in loop 229 through steps 213, 214.
  • [0166]
    Once registered on the job available queue 206, in steps 218, 220, 222, and 224, child job 202 waits for work by looping using a select( ) socket call for a timer, and in step 226 socket macros monitor and process data from active descriptors (clients) 120-124. With this scheme, blocking is avoided on either an accept( ) or a takedescriptor( ) call until the parent job 200 performs a “wakeup” via a connect( ) request to one of the active descriptors. (While “descriptor” is “socket”, which is also “port” plus “address”, here port is used loosely, to mean socket.) As part of the “wakeup”, in step 318 parent job 200 sends its job identifier to the child, which the child uses in step 216 for the call to takedescriptor( ) that receives the “handoff” from parent job 200. Session ID strings 600, 602 are transmitted on lines 555 and 557. A job identifier is used as a parameter to a givedescriptor( ) call 246 or 216, and as a value stacked onto queue object 206. The value stacked on queue 206 is obtained by parent job 200 for use in step 318.
  • [0167]
    In step 216, the takedescriptor( ) provides child 202 with its own descriptor for the connection, separate from the descriptor used in parent 200.
  • [0168]
    To further insure that parent WSG server job was the 5250/HTML workstation gateway server 420 from which the socket is received, in step 217 the getsockname( ) socket call is used to match the local port of the socket with that configured in the TCP/IP services database 444 (FIG. 3.) This is done to assure that “our own” server did the givedescriptor( ) socket call, because takedescriptor( ) works with any kind of server, such as FTP, Telnet, and so forth, and that is NOT wanted. Givedescriptor( ) uses job identifiers as a parameter. Job identifiers uniquely identify an AS/400 batch job, such that WSG servers can be distinguished from one another. A descriptor is synonymous with socket; thus, the handoff previously described refers to sockets, and works by the parent doing a givedescriptor( ) call to give the socket to the child job. The child job does a takedescriptor( ) to get the socket from the parent. As part of the takedescriptor( ), the child job uses the parent's job identifier to insure it only takes sockets from the WSG parent job, and only that parent job. The parents job is is passed as part of the “wakeup”.
  • [0169]
    Open/Write to the AS/400 virtual terminal session: Referring further to FIG. 8A, if this is a new connect request (step 219 evaluates true), in step 221, child job 202 will open a virtual terminal session 500. Then, for either new or active connections, in step 223 child 200 reads the request (on line 539, 557) from the browser 120-124, parses the HTTP headers, and the body of the request is processed into a 5250 data stream and sent inbound into the operating system, loosely represented by blocks 500 and 502 (a clear demarcation of the operating system is not presented in the figures.)
  • [0170]
    Read from the AS/400 virtual terminal session: The child job waits in step 225 for a queue notification from the virtual terminal session 500, indicating reply data is pending. Branch 225 is called if branch 224 is true. An active socket can be either a new connection or an old connection that has not yet finished and done the yes branch on block 225. When a virtual terminal session has a response, virtual terminal manager 416 stacks a notification on the virtual terminal queue 417 provided by start up program 300 in step 302. This queue 417 is checked in step 225 by gateway 420. In step 233, child job 200 both reads and writes to the virtual terminal: it reads (line 531, step 226, 256) in the response and builds/updates an AS/400 screen image in buffers using the response data. Several buffers are maintained, including:
  • [0171]
    1) EBCDIC screen image buffer
  • [0172]
    2) Embedded HTML buffer
  • [0173]
    3) Field Format Table (input fields buffer)
  • [0174]
    4) Attributes buffer
  • [0175]
    Write to the client session: If all the reply data (via block 430) from the virtual terminal 500 has been received (step 227 evaluates true), in step 234 child 202 calls the Screen Analysis and Construction (SAC) functions to build/update the SAC screen objects. The output of the SAC functions are called Static Intermediate Representation (SIR) objects. These objects are not yet in HTML format—they are translated in step 234 into HTML markup tags along with any embedded HTML buffer entries into the final HTML form that is sent to browser 120-124.
  • [0176]
    Child 202, 420, 422 formats the AS/400 panel image as an HTML form. This form is returned (line 541, 557) to the client, such as a client 120-124 machine on TCP/IP network 450, along with the appropriate HTTP header lines:
  • [0177]
    status-line CRLF
  • [0178]
    header-line(s) CRLF
  • [0179]
    CRLF
  • [0180]
    entity-body (HTML form)
  • [0181]
    Log request/response: The AS/400 410-414 indicates (step 227 evaluates true) when all reply data has been sent through the 5250 data stream (the 5250 data stream does not necessarily arrive all in one piece). Therefore, no HTML form is sent back (line 541, 555, step 234) to the client 120-124, 450 until the AS/400 indicates all data has been received.
  • [0182]
    Monitor and close inactive clients: If a client session is inactive for a period of time longer than the configured timeout value (step 235), then in step 236 that child job 202 closes the clients virtual terminal session. However, the listening socket associated with that client is not closed, but in step 237 is marked as available and re-used.
  • [0183]
    Re-register for new work: If a client session has been inactive too long (step 235 evaluates true) or the client logs off (step 238 evaluates true), in step 231 child job 202 makes the session available again for new clients. This is done be re-queuing a job identifier 336-340 for the child 202 back onto job available queue 206. A session timer (step 235) is maintained to track inactivity for each client 120-124. In step 228, child job 202 will also check that a sufficient number of available sessions exist, and in step 230 will prestart another child job if the number available is below threshold (threshold algorithm TBD). Furthermore, if the number of available sessions is greater than the threshold value, in step 239 child job 202 checks to see if it can safely exit and still leave sufficient available jobs to stay above the threshold value. As long as no established or active sessions (each session possibly containing several sockets) still belong in the job (each job possibly containing several sessions) and the threshold limit is maintained even with the loss of the child jobs (step 241 evaluates true), in step 243 child 202 can exit.
  • ALTERNATIVE EMBODIMENTS
  • [0184]
    It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the Invention. In particular, it is within the scope of the invention to provide a memory device, such as a transmission medium, magnetic or optical tape or disc, or the like, for storing signals for controlling the operation of a computer according to the method of the invention and/or to structure its components in accordance with the system of the invention.

Claims (19)

    We claim:
  1. 1. In an Internet system having a plurality of applications, a plurality of servers for attachment from a plurality of web browsers, the improvement wherein said system supports connection oriented applications over a connectionless protocol and wherein at least one of said servers is a master server work station gateway owning a well-known port, and the other servers are slave servers supporting established web browser-to-application state session.
  2. 2. The Internet system of
    claim 1
    wherein each slave server notifies the master server how many browser sessions it can support.
  3. 3. The Internet system of
    claim 2
    wherein each slave server notifies the master server whenever an established browser-to-application session is ended.
  4. 4. The Internet system of
    claim 1
    wherein the slave servers and the master server communicate through a common queue object, wherein an entry is enqueued when a slave server slot is available for a browser session, and an entry is dequeued when a browser session is established.
  5. 5. A workstation gateway server system supporting connection oriented applications over a connectionless protocol, comprising:
    a server parent job;
    at least one child job;
    said server parent job detecting connection requests from network browsers and handing said connection requests to said child job;
    said child job satisfying said connection requests while maintaining the illusion that the connection requestor is logically connected to said application across a plurality of disconnected transactions.
  6. 6. The system of
    claim 5
    wherein said server parent job owns a well-known port.
  7. 7. The system of
    claim 6
    wherein said child job supports at least one established browser-to-application state session.
  8. 8. The system of
    claim 7
    further comprising a common queue object for communications between said parent job and said child job.
  9. 9. The system of
    claim 8
    wherein each said child job is operable to enqueue on said common queue object one or more slot available entries, and said parent job is operable to dequeue from said common queue object a slot available entry for each session it dispatches to said child job.
  10. 10. The system of
    claim 9
    wherein said child job is operable upon completion of a session to enqueue in said common queue object a slot available entry.
  11. 11. The system of
    claim 9
    wherein said server parent job is operable responsive to the number of slot available entries in said common queue object to start another child job.
  12. 12. The system of
    claim 10
    wherein said server parent job is operable responsive to the number of slot available entries in said common queue object to terminate a child job.
  13. 13. The system of
    claim 9
    wherein said child job is operable responsive to the number of slot available entries in said common queue object to start another child job.
  14. 14. The system of
    claim 10
    wherein said child job is operable responsive to the number of slot available entries in said common queue object to terminate a child job.
  15. 15. The system of
    claim 6
    wherein said child job determines that a server parent job is already running upon receiving a socket error when attempting to bind to said port.
  16. 16. The system of
    claim 7
    wherein said child job blocks only when said server parent job is attempting to dispatch a new session to it.
  17. 17. A method for operating a computing system for connecting a plurality of applications and clients through a single server, the server maintaining the illusion of a connectionless-oriented environment to the client and a connection-oriented environment to the application, comprising the steps of:
    executing a startup program according to the steps of:
    providing a job available queue;
    providing a virtual terminal queue;
    starting a parent job; and
    starting a first child job;
    executing said parent job according to the steps of:
    monitoring a configured port for a client connect request;
    responsive to receiving a request from a client to connect to an application, dequeueing a free child job identifier from said job available queue and dispatching to said free child job a client connect request;
    responsive to said job available queue approaching empty, starting a new child job; and
    executing said child job according to the steps of:
    registering for new work by enqueuing one or more of its job identifiers on said job available queue;
    listening on active ports;
    opening and selectively writing an application session;
    selectively reading from said application session;
    writing to a client session;
    monitoring and closing inactive clients; and
    reregistering for new work on said job available queue.
  18. 18. A memory device for controlling the operation of a computer according to the steps of connecting a plurality of applications and clients through a single server, the server maintaining the illusion of a connectionless-oriented environment to the client and a connection-oriented environment to the application.
  19. 19. The method of connecting a client to an application, comprising the steps of
    maintaining in a job available queue a plurality of identifiers of available child jobs;
    responsive to a request from a client to connect to an application, operating a server parent job to dequeue from said job available queue the identifier of a next available child job and dispatch said request to said available child job; and
    operating said available child job to establish a connectionless-oriented communications environment for said client and a virtual connection-oriented communications environment for said application.
US09394568 1996-06-03 1999-09-10 Multiplexing of clients and applications among multiple servers Expired - Fee Related US6345291B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US1912896 true 1996-06-03 1996-06-03
US08785915 US6006266A (en) 1996-06-03 1997-01-21 Multiplexing of clients and applications among multiple servers
US09394568 US6345291B2 (en) 1996-06-03 1999-09-10 Multiplexing of clients and applications among multiple servers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09394568 US6345291B2 (en) 1996-06-03 1999-09-10 Multiplexing of clients and applications among multiple servers

Publications (2)

Publication Number Publication Date
US20010047392A1 true true US20010047392A1 (en) 2001-11-29
US6345291B2 US6345291B2 (en) 2002-02-05

Family

ID=26691880

Family Applications (2)

Application Number Title Priority Date Filing Date
US08785915 Expired - Fee Related US6006266A (en) 1996-06-03 1997-01-21 Multiplexing of clients and applications among multiple servers
US09394568 Expired - Fee Related US6345291B2 (en) 1996-06-03 1999-09-10 Multiplexing of clients and applications among multiple servers

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08785915 Expired - Fee Related US6006266A (en) 1996-06-03 1997-01-21 Multiplexing of clients and applications among multiple servers

Country Status (1)

Country Link
US (2) US6006266A (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020051187A1 (en) * 2000-06-05 2002-05-02 Murata Kikai Kabushiki Kaisha Web server and facsimile machine having web server function
US6789110B1 (en) * 1999-10-22 2004-09-07 Nomadix, Inc. Information and control console for use with a network gateway interface
US20060053216A1 (en) * 2004-09-07 2006-03-09 Metamachinix, Inc. Clustered computer system with centralized administration
US7454457B1 (en) * 2000-02-07 2008-11-18 Parallel Networks, Llc Method and apparatus for dynamic data flow control using prioritization of data requests
US7539198B1 (en) * 2002-06-26 2009-05-26 Cisco Technology, Inc. System and method to provide node-to-node connectivity in a communications network
US20100061233A1 (en) * 2008-09-11 2010-03-11 International Business Machines Corporation Flow control in a distributed environment
US7689716B2 (en) 1998-12-08 2010-03-30 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US8027339B2 (en) 1997-03-12 2011-09-27 Nomadix, Inc. System and method for establishing network connection
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US8725836B2 (en) 2000-02-07 2014-05-13 Parallel Networks, Llc Method and apparatus for content synchronization

Families Citing this family (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6108655A (en) * 1996-07-19 2000-08-22 Cisco Technology, Inc. Method and apparatus for transmitting images and other objects over a computer network system
US6058474A (en) * 1997-01-24 2000-05-02 Texas Instruments Incorporated Method and apparatus for DMA boot loading a microprocessor without an internal ROM
US6192389B1 (en) * 1997-03-28 2001-02-20 International Business Machines Corporation Method and apparatus for transferring file descriptors in a multiprocess, multithreaded client/server system
US6061741A (en) * 1997-05-28 2000-05-09 International Business Machines Corporation Method and apparatus for synchronization of connectionless applications across a network by using simple encryption tokens
US6675195B1 (en) * 1997-06-11 2004-01-06 Oracle International Corporation Method and apparatus for reducing inefficiencies caused by sending multiple commands to a server
US6360262B1 (en) * 1997-11-24 2002-03-19 International Business Machines Corporation Mapping web server objects to TCP/IP ports
US7346689B1 (en) * 1998-04-20 2008-03-18 Sun Microsystems, Inc. Computer architecture having a stateless human interface device and methods of use
US6446225B1 (en) * 1998-04-23 2002-09-03 Microsoft Corporation Server system with scalable session timeout mechanism
US7177910B1 (en) * 1998-07-21 2007-02-13 Globespanvirata, Inc. System and method for communicating in a point-to-multipoint DSL network
DE69827639D1 (en) * 1998-09-11 2004-12-23 Two Way Media Ltd Delivery of interactive applications
US6195682B1 (en) * 1998-10-27 2001-02-27 International Business Machines Corporation Concurrent server and method of operation having client-server affinity using exchanged client and server keys
US6473424B1 (en) 1998-12-02 2002-10-29 Cisco Technology, Inc. Port aggregation load balancing
US6934293B1 (en) 1998-12-02 2005-08-23 Cisco Technology, Inc. Port aggregation load balancing
US6751191B1 (en) 1999-06-29 2004-06-15 Cisco Technology, Inc. Load sharing and redundancy scheme
US6557038B1 (en) * 1999-06-30 2003-04-29 International Business Machines Corporation Method and apparatus for maintaining session states
US7065779B1 (en) * 1999-10-13 2006-06-20 Cisco Technology, Inc. Technique for synchronizing multiple access controllers at the head end of an access network
WO2001031885A3 (en) 1999-10-22 2002-01-17 Nomadix Inc Gateway device having an xml interface and associated method
US7171473B1 (en) * 1999-11-17 2007-01-30 Planet Exchange, Inc. System using HTTP protocol for maintaining and updating on-line presence information of new user in user table and group table
CA2293062A1 (en) * 1999-12-22 2001-06-22 Ibm Canada Limited-Ibm Canada Limitee Efficient use of domain socket pairs in communication for tightly coupled transactions
EP1283996A2 (en) * 2000-01-31 2003-02-19 Mobileq Canada Inc. Method and system for reusing internet-based applications
US6839829B1 (en) 2000-01-18 2005-01-04 Cisco Technology, Inc. Routing protocol based redundancy design for shared-access networks
US7058007B1 (en) 2000-01-18 2006-06-06 Cisco Technology, Inc. Method for a cable modem to rapidly switch to a backup CMTS
WO2001055862A1 (en) * 2000-01-28 2001-08-02 Ibeam Broadcasting Corporation Method and system for real-time distributed data mining and analysis for networks
US6742044B1 (en) 2000-05-10 2004-05-25 Cisco Technology, Inc. Distributed network traffic load balancing technique implemented without gateway router
US6789125B1 (en) 2000-05-10 2004-09-07 Cisco Technology, Inc. Distributed network traffic load balancing technique implemented without gateway router
US7395348B1 (en) 2000-06-05 2008-07-01 Cisco Technology, Inc. Network cache-based content routing
US6938080B1 (en) * 2000-06-07 2005-08-30 Nortel Networks Limited Method and computer system for managing data exchanges among a plurality of network nodes in a managed packet network
US6981056B1 (en) 2000-06-28 2005-12-27 Cisco Technology, Inc. Wide area load balancing of web traffic
US7072979B1 (en) 2000-06-28 2006-07-04 Cisco Technology, Inc. Wide area load balancing of web traffic
US7069324B1 (en) 2000-06-30 2006-06-27 Cisco Technology, Inc. Methods and apparatus slow-starting a web cache system
US7062571B1 (en) 2000-06-30 2006-06-13 Cisco Technology, Inc. Efficient IP load-balancing traffic distribution using ternary CAMs
US7366755B1 (en) * 2000-07-28 2008-04-29 International Business Machines Corporation Method and apparatus for affinity of users to application servers
US7028051B1 (en) 2000-09-29 2006-04-11 Ugs Corp. Method of real-time business collaboration
WO2002037218A3 (en) * 2000-10-30 2003-01-23 Kirk Beach Paperless coupon redemption method and apparatus
US6795858B1 (en) 2000-12-29 2004-09-21 Cisco Technology, Inc. Method and apparatus for metric based server selection
US7043752B2 (en) * 2001-01-12 2006-05-09 Siemens Medical Solutions Health Services Corporation System and user interface supporting concurrent application initiation and interoperability
US7334031B2 (en) * 2001-01-12 2008-02-19 Siemens Medical Solutions Health Services Corporation System and user interface supporting processing and activity management for concurrently operating applications
US7062562B1 (en) 2001-04-11 2006-06-13 Cisco Technology, Inc. Methods and apparatus for content server selection
US7080138B1 (en) 2001-04-11 2006-07-18 Cisco Technology, Inc. Methods and apparatus for content server selection
US7881208B1 (en) 2001-06-18 2011-02-01 Cisco Technology, Inc. Gateway load balancing protocol
DE10129371B4 (en) * 2001-06-20 2006-06-14 T-Mobile Deutschland Gmbh A process for the automatic routing of information
US7085287B1 (en) 2001-06-27 2006-08-01 Cisco Technology, Inc. Map routing technique implemented in access networks
US7349430B1 (en) 2001-06-27 2008-03-25 Cisco Technology, Inc. Addressing scheme implemented in access networks
US7363376B2 (en) * 2001-07-31 2008-04-22 Arraycomm Llc Method and apparatus for generating an identifier to facilitate delivery of enhanced data services in a mobile computing environment
JP4158365B2 (en) * 2001-08-27 2008-10-01 ブラザー工業株式会社 Network terminal device
US7227863B1 (en) 2001-11-09 2007-06-05 Cisco Technology, Inc. Methods and apparatus for implementing home agent redundancy
US7031473B2 (en) * 2001-11-13 2006-04-18 Microsoft Corporation Network architecture for secure communications between two console-based gaming systems
US7227838B1 (en) 2001-12-14 2007-06-05 Cisco Technology, Inc. Enhanced internal router redundancy
US8635305B1 (en) 2001-12-19 2014-01-21 Cisco Technology, Inc. Mechanisms for providing differentiated services within a web cache
US7720997B1 (en) 2001-12-19 2010-05-18 Cisco Technology, Inc. Path selection system
US20030182398A1 (en) * 2002-02-14 2003-09-25 Morlang Keven P. Method of establishing a logical association between connections
US7096249B2 (en) * 2002-03-29 2006-08-22 Intel Corporation Method and system for distributing applications
US8910241B2 (en) * 2002-04-25 2014-12-09 Citrix Systems, Inc. Computer security system
US7644434B2 (en) * 2002-04-25 2010-01-05 Applied Identity, Inc. Computer security system
US7356711B1 (en) 2002-05-30 2008-04-08 Microsoft Corporation Secure registration
US7370194B2 (en) * 2002-06-10 2008-05-06 Microsoft Corporation Security gateway for online console-based gaming
US8117328B2 (en) * 2002-06-25 2012-02-14 Microsoft Corporation System and method for automatically recovering from failed network connections in streaming media scenarios
US7480724B2 (en) 2002-09-25 2009-01-20 At&T Intellectual Property I, L.P. API tool-set for providing services through a residential communication gateway
US20050038869A1 (en) * 2002-09-25 2005-02-17 Randy Zimler Business portal API
US7584263B1 (en) 2002-09-25 2009-09-01 At&T Intellectual Property I, L. P. System and method for providing services access through a family home page
CA2406713C (en) * 2002-10-04 2009-06-30 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for relaying session information from a portal server
CA2406569C (en) * 2002-10-04 2011-03-22 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for enabling associated portlets of a web portal to collaborate for synchronized content display
CA2406565A1 (en) * 2002-10-04 2004-04-04 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for using business rules or user roles for selecting portlets in a web portal
US7814232B2 (en) 2003-03-28 2010-10-12 Cisco Technology, Inc. Network address translation with gateway load distribution
US7593346B2 (en) * 2003-07-31 2009-09-22 Cisco Technology, Inc. Distributing and balancing traffic flow in a virtual gateway
WO2005066737A1 (en) * 2003-12-31 2005-07-21 Applied Identity Method and system for establishing the identity of an originator of computer transactions
US20050166053A1 (en) * 2004-01-28 2005-07-28 Yahoo! Inc. Method and system for associating a signature with a mobile device
US7840988B1 (en) 2004-05-07 2010-11-23 Cisco Technology, Inc. Front-end structure for access network line card
US8180883B1 (en) 2004-08-02 2012-05-15 Cisco Technology, Inc. Method and system for processing directives included in management events
US20060107323A1 (en) * 2004-11-16 2006-05-18 Mclean Ivan H System and method for using a dynamic credential to identify a cloned device
US8059661B2 (en) 2004-12-29 2011-11-15 Cisco Technology, Inc. Methods and apparatus for using DHCP for home address management of nodes attached to an edge device and for performing mobility and address management as a proxy home agent
US7623455B2 (en) * 2005-04-02 2009-11-24 Cisco Technology, Inc. Method and apparatus for dynamic load balancing over a network link bundle
US7813485B2 (en) * 2005-05-26 2010-10-12 International Business Machines Corporation System and method for seamlessly integrating an interactive visual menu with an voice menu provided in an interactive voice response system
US8620315B1 (en) 2006-09-29 2013-12-31 Yahoo! Inc. Multi-tiered anti-abuse registration for a mobile device user
US8151118B2 (en) * 2007-01-29 2012-04-03 Microsoft Corporation Master-slave security devices
US20080184341A1 (en) * 2007-01-29 2008-07-31 David Jaroslav Sebesta Master-Slave Protocol for Security Devices
US20100115242A1 (en) * 2007-03-29 2010-05-06 Kenshin Yamada Engine/processor cooperation system and cooperation method
EP2224339A3 (en) * 2007-09-12 2011-03-16 Citrix Systems, Inc. Methods and systems for generating desktop environments providing integrated access to remote and local resources
US7911948B2 (en) * 2007-10-17 2011-03-22 Viasat, Inc. Methods and systems for performing TCP throttle
US8516539B2 (en) * 2007-11-09 2013-08-20 Citrix Systems, Inc System and method for inferring access policies from access event records
US8990910B2 (en) * 2007-11-13 2015-03-24 Citrix Systems, Inc. System and method using globally unique identities
US8667175B2 (en) 2008-03-13 2014-03-04 Cisco Technology, Inc. Server selection for routing content to a client using application layer redirection
US9240945B2 (en) * 2008-03-19 2016-01-19 Citrix Systems, Inc. Access, priority and bandwidth management based on application identity
US8943575B2 (en) 2008-04-30 2015-01-27 Citrix Systems, Inc. Method and system for policy simulation
US8990573B2 (en) * 2008-11-10 2015-03-24 Citrix Systems, Inc. System and method for using variable security tag location in network communications
US8700723B2 (en) * 2010-06-15 2014-04-15 Netzyn, Inc. Hierarchical display-server system and method

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0403229A1 (en) * 1989-06-13 1990-12-19 Digital Equipment Corporation Method and apparatus for scheduling tasks in repeated iterations in a digital data processing system having multiple processors
US5278984A (en) * 1990-12-19 1994-01-11 Bull Hn Information Systems Inc. Method for managing requests by specifying time intervals for transmitting a minimum number of messages for specific destinations and priority levels
US5768594A (en) * 1995-07-14 1998-06-16 Lucent Technologies Inc. Methods and means for scheduling parallel processors
US5761507A (en) * 1996-03-05 1998-06-02 International Business Machines Corporation Client/server architecture supporting concurrent servers within a server with a transaction manager providing server/connection decoupling
US5754772A (en) * 1996-03-26 1998-05-19 Unisys Corporation Transaction service independent HTTP server-to-transaction gateway
US5754830A (en) * 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US5961601A (en) * 1996-06-07 1999-10-05 International Business Machines Corporation Preserving state information in a continuing conversation between a client and server networked via a stateless protocol
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6038562A (en) * 1996-09-05 2000-03-14 International Business Machines Corporation Interface to support state-dependent web applications accessing a relational database
US5872915A (en) * 1996-12-23 1999-02-16 International Business Machines Corporation Computer apparatus and method for providing security checking for software applications accessed via the World-Wide Web

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8027339B2 (en) 1997-03-12 2011-09-27 Nomadix, Inc. System and method for establishing network connection
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US7689716B2 (en) 1998-12-08 2010-03-30 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US6789110B1 (en) * 1999-10-22 2004-09-07 Nomadix, Inc. Information and control console for use with a network gateway interface
US8296451B2 (en) 2000-02-07 2012-10-23 Parallel Networks, Llc Method and apparatus for dynamic data flow control using prioritization of data requests
US7454457B1 (en) * 2000-02-07 2008-11-18 Parallel Networks, Llc Method and apparatus for dynamic data flow control using prioritization of data requests
US8756342B1 (en) 2000-02-07 2014-06-17 Parallel Networks, Llc Method and apparatus for content synchronization
US8725836B2 (en) 2000-02-07 2014-05-13 Parallel Networks, Llc Method and apparatus for content synchronization
US9124594B2 (en) 2000-02-07 2015-09-01 Parallel Networks, Llc Method and apparatus for dynamic data flow control using prioritization of data requests
US8099457B2 (en) 2000-02-07 2012-01-17 Parallel Networks, Llc Method and apparatus for dynamic data flow control using prioritization of data requests
US20090077173A1 (en) * 2000-02-07 2009-03-19 Parallel Networks Llc Method and Apparatus for Dynamic Data Flow Control Using Prioritization of Data Requests
US20020051187A1 (en) * 2000-06-05 2002-05-02 Murata Kikai Kabushiki Kaisha Web server and facsimile machine having web server function
US6943910B2 (en) * 2000-06-05 2005-09-13 Murata Kikai Kabushiki Kaisha Web server and facsimile machine having web server function
US7539198B1 (en) * 2002-06-26 2009-05-26 Cisco Technology, Inc. System and method to provide node-to-node connectivity in a communications network
US20060053216A1 (en) * 2004-09-07 2006-03-09 Metamachinix, Inc. Clustered computer system with centralized administration
US20100061233A1 (en) * 2008-09-11 2010-03-11 International Business Machines Corporation Flow control in a distributed environment
US9282151B2 (en) * 2008-09-11 2016-03-08 International Business Machines Corporation Flow control in a distributed environment

Also Published As

Publication number Publication date Type
US6345291B2 (en) 2002-02-05 grant
US6006266A (en) 1999-12-21 grant

Similar Documents

Publication Publication Date Title
US7921686B2 (en) Highly scalable architecture for application network appliances
US6032147A (en) Method and apparatus for rationalizing different data formats in a data management system
US6247044B1 (en) Apparatus and method for processing servlets
US6952714B2 (en) Method for distributed program execution with server-based file type association
US5596579A (en) High performance machine for switched communications in a heterogeneous data processing network gateway
US6012090A (en) Client-side parallel requests for network services using group name association
US6351775B1 (en) Loading balancing across servers in a computer network
US5878225A (en) Dual communication services interface for distributed transaction processing
US7111303B2 (en) Virtual machine operating system LAN
US5396630A (en) Method and system for object management across process boundries in a data processing system
US5021949A (en) Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network
US6907463B1 (en) System and method for enabling file transfers executed in a network environment by a software program
US7373500B2 (en) Secure network processing
US5617570A (en) Server for executing client operation calls, having a dispatcher, worker tasks, dispatcher shared memory area and worker control block with a task memory for each worker task and dispatcher/worker task semaphore communication
US6047338A (en) System for transferring a data directly from/to an address space of a calling program upon the calling program invoking a high performance interface for computer networks
US7111006B2 (en) System and method for providing distributed database services
US6810421B1 (en) Communication network system and method for controlling services in a communication network system
US6175920B1 (en) Expedited message control for synchronous response in a Kerberos domain
US4893307A (en) Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network
US4800488A (en) Method of propagating resource information in a computer network
US6477585B1 (en) Filter mechanism for an event management service
US6898633B1 (en) Selecting a server to service client requests
US20050203944A1 (en) Apparatus, system, and method for facilitating transactions between thin-clients and message format service (MFS)-based information management system (IMS) applications
US20040230660A1 (en) Cascading network apparatus for scalability
US6324574B1 (en) Relay server for unsigned applets

Legal Events

Date Code Title Description
FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
FP Expired due to failure to pay maintenance fee

Effective date: 20100205