Multi-version processing using the monitor subsystem

Abstract

To service requests from client subsystems to perform analysis of sequencing data, the version of the sequencing system can be monitored to allow changes to the version of the server subsystem operating the sequencing system. The monitor subsystem can be utilized to receive and authorize requests from client subsystems. The monitor subsystem can identify a version associated with the server subsystem operating the sequencing system implemented to service the request. The monitor subsystem can allow the server subsystem to be accessed to service a request from a client subsystem when the version associated with the client subsystem is compatible with the version associated with the server subsystem. The monitor subsystem can prevent the server subsystem from being accessed when the version associated with the client subsystem is incompatible with the version associated with the server subsystem.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 408,235, filed September 20, 2022, which is incorporated herein by reference in its entirety. [Background technology]

[0002] Sequencing platforms provide rapid and accurate secondary and tertiary genomic analysis of sequencing data. Platforms can span hardware and software to deliver complete sequencing solutions. In a single-process (SP) environment, a single application can run at a time on a single field-programmable gate array (FPGA) installed on a server device. A single version of software may be installed on the server device at a given time. Users with specific version requirements can install their desired software version and run their application.

[0003] In a multi-processing (MP) environment, multiple applications can run simultaneously on a set of FPGA hardware. Several users can run sequencing jobs simultaneously. Because a sequencing solution may span multiple layers of software and hardware, it is difficult to support client software applications running different versions of sequencing software on the server device. Summary of the Invention [Means for solving the problem]

[0004] Described herein are systems, methods, and apparatus for monitoring the version of a sequencing system and allowing changes to the version of a server subsystem operating the sequencing system to service requests from client subsystems to perform analysis of sequencing data. A monitor subsystem can be utilized to receive requests from client subsystems. The requests may include a version associated with the client subsystem on which the request was received. The monitor subsystem can identify a version associated with the server subsystem operating the sequencing system implemented to service the request. The monitor subsystem can allow the server subsystem to be accessed to service a request from a client subsystem when the version associated with the client subsystem is compatible with the version associated with the server subsystem. The monitor subsystem can prevent the server subsystem from being accessed when the version associated with the client subsystem is incompatible with the version associated with the server subsystem. The monitor subsystem can identify a change in the version associated with the server subsystem to allow requests from client subsystems that were previously prevented from accessing the server subsystem due to version incompatibility.

[0005] The monitor subsystem may continue to accept requests from client subsystems associated with the compatible version while the server subsystem continues to operate the same version of the sequencing system. When the monitor subsystem determines that the server subsystem or a process running thereon is idle, the monitor subsystem may cause the server subsystem to change versions to process requests from client subsystems operating with other versions of the sequencing application. Changing from a first version to a second version involves decomposing and building at least one software layer in the vertical solution stack.

[0006] Each version of the server subsystem may include different features for bioinformatics components associated with processing different requests. Different bioinformatics components may be utilized by loading different bioinformatics components onto one or more field programmable gate arrays (FPGAs). Different versions of the server subsystem may support different bioinformatics components loaded onto one or more FPGAs to support the same or different sequencing tasks. Sequencing tasks may include tasks performed in secondary or tertiary analysis of sequencing data. Secondary or tertiary analysis may include alignment, sorting, or variant calling based on sequencing data.

[0007] The monitor subsystem may be a daemon process. The server subsystem may be a daemon process that runs at least partially on the client device or the server device. The daemon process may be one of multiple predefined daemon processes in the server subsystem.

[0008] The monitor subsystem can prevent the server subsystem from being accessed by the client subsystem by preventing an access key from being transmitted to the client subsystem or a connection from being established between the client subsystem and the server subsystem. The monitor subsystem can allow the server subsystem to be accessed by the client subsystem by providing an access key to the client subsystem. The monitor subsystem can notify the server subsystem that an access key has been provided to the client subsystem.

[0009] The client subsystem can receive a message indicating that the client subsystem is blocked. The client subsystem can wait to receive an indication from the monitor subsystem indicating that the request can be processed. The client subsystem can receive an access key and transmit a message to the server subsystem including the access key to establish a connection with the server subsystem.

[0010] A request may be received by the monitor subsystem from the client subsystem via a socket. Access may be granted to the server subsystem through the socket via an access key. The monitor subsystem may monitor signals from the child process to detect a terminal signal to resume the child process. [Brief explanation of the drawings]

[0011] [Figure 1A] A schematic diagram of the system environment is shown. [Figure 1B] FIG. 1 illustrates a system including a monitor subsystem that can be utilized in managing requests from client sequencing applications on client subsystems operating at different versions. [Figure 1C] 1 illustrates examples of one or more bioinformatics subsystems that may be implemented by a sequencing system operating on a server subsystem to perform secondary and / or tertiary forms of sequencing analysis. [Figure 2] 10 is a flowchart illustrating an exemplary procedure for monitoring the version of a server subsystem and processing requests from a compatible client subsystem. [Figure 3] FIG. 1 is a block diagram of an exemplary computing device. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1A shows a schematic diagram of a system environment (or "environment") 100 described herein. As shown, the environment 100 includes one or more server devices 102 connected to one or more client devices 108 and a sequencing device 114 via a network 112.

[0013] 1A , the server device 102, the client device 108, and the sequencing device 114 can communicate with each other via a network 112. The network 112 can include any suitable network over which computing devices can communicate. The network 112 can include a wired and / or wireless communication network. An exemplary wireless communication network can be comprised of one or more types of radio frequency (RF) communication signals using one or more wireless communication protocols, such as a cellular communication protocol, a wireless local area network (WLAN), a Wi-Fi communication protocol, and / or another wireless communication protocol. In addition to, or instead of, communicating over the network 112, the server device 102, the client device 108, and / or the sequencing device 114 can bypass the network 112 and communicate directly with each other.

[0014] 1A, environment 100 may include database 116. Database 116 may store information for access by devices in environment 100. Server device 102, client device 108, and / or sequencing device 114 may communicate with database 116 (e.g., directly or via network 112) to store and / or access information.

[0015] As shown in FIG. 1A, the sequencing device 114 can include a device for sequencing a biological sample. The biological sample can include human and / or non-human deoxyribonucleic acid (DNA) for determining individual nucleotide bases of a nucleic acid sequence (e.g., sequencing by synthesis). The biological sample can include human and / or non-human ribonucleic acid (RNA). The sequencing device 114 can analyze nucleic acid segments and / or oligonucleotides extracted from the sample to generate nucleotide reads and / or other data using the computer-implemented methods and systems described herein, either directly or indirectly on the sequencing device 114. More specifically, the sequencing device 114 can receive and analyze nucleic acid sequences extracted from the sample within a nucleotide-sample slide (e.g., a flow cell). The sequencing device 114 can sequence nucleic acid segments into nucleotide reads using sequencing by synthesis (SBS).

[0016] 1A, the server device 102 can generate, receive, analyze, store, and / or transmit digital data, such as data for determining nucleotide-base calls or sequencing a nucleic acid polymer. As shown in FIG. 1A, the sequencing device 114 can generate and transmit (and the server device 102 can receive) nucleotide reads and / or other sequencing data for analysis by the server device 102 for base calling and / or variant calling. The server device 102 can also communicate with the client device 108. In particular, the server device 102 can transmit data, including sequencing data or other information, to the client device 108, and the server device 102 can receive input from a user via the client device 108.

[0017] The server device 102 may include a distributed collection of servers, and may include several server devices distributed across the network 112 and located in the same or different physical locations. Furthermore, the server device 102 may include a content server, an application server, a communication server, a web hosting server, or another type of server.

[0018] 1A , the server device 102 and / or the sequencing device 114 may include a server subsystem 104. The server subsystem 104 may include software and / or hardware utilized by the server device 102 to process sequencing requests and / or data, as described herein. The server subsystem 104 may be included in a single server device 102 or sequencing device 114, or may be distributed across multiple devices. The server subsystem 104 may include a sequencing system spanning multiple layers of software and / or hardware for servicing requests for sequencing services at the server subsystem 104.

[0019] The server subsystem 104 can analyze nucleotide reads and / or other data, such as sequencing metrics, received from the sequencing device 114 to determine the nucleotide base sequence for the nucleic acid polymer. For example, the server subsystem 104 can receive raw data from the sequencing device 114 and determine the nucleotide base sequence for the nucleic acid segment. The server subsystem 104 can process the sequencing data to determine the sequence of nucleotide bases in DNA and / or RNA segments or oligonucleotides. In addition to processing and determining the sequence for the biological sample, the server subsystem 104 can generate files for processing and / or transmission to other devices.

[0020] Each client device 108 can generate, store, receive, and / or transmit digital data. Specifically, a client device 108 can receive sequencing metrics from a sequencing device 114. Additionally, a client device 108 can communicate with the server device 102 to receive one or more files containing nucleic acid base calls and / or other metrics. A client device 108 can present or display information regarding the nucleotide-base calls in a graphical user interface to a user associated with the client device 108.

[0021] 1A can include various types of client devices. In examples, the client devices 108 can include non-mobile devices such as desktop computers or servers, or other types of client devices. In other examples, the client devices 108 can include mobile devices such as laptops, tablets, mobile phones, or smartphones.

[0022] 1A , each client device 108 can include one or more client subsystems 110. The server device 102 and / or the sequencing device 114 may also, or alternatively, include one or more client subsystems. Each client subsystem 110 may include software and / or hardware utilized by a client process to process sequencing requests and / or data, as described herein. The client subsystems 110 can span multiple layers of software and / or hardware. The client subsystems 110 may be included on a single device or distributed across multiple devices.

[0023] The client subsystem 110 may include a sequencing application. The sequencing application may be a remote application or a native application stored and executed on a local device. The sequencing application may include instructions that (when executed) cause the client device 108 to receive data from the sequencing device 114 and / or the server device 102 and present the data to a user of the client device 108 for display on the client device 108.

[0024] Multiple client requests from client subsystems 110 may be received at the server subsystem 104 to perform sequencing services. The client subsystems 110 transmitting the requests may operate using different versions of a sequencing application to analyze the sequencing data. In one embodiment, different versions of the sequencing application may support different types of analysis for the same or different types of sequencing devices 144. The server subsystem 104 of the server device 102 may load and execute different versions of a sequencing system to support client sequencing applications operating on different versions of software in the client subsystem 110. Different versions of the sequencing system may span multiple layers of software and / or hardware in the server subsystem 104. For example, different versions of the sequencing system may span multiple software and / or hardware layers of a vertical solution stack.

[0025] Requests received by the server subsystem 104 from client subsystems 110 running on different versions of software can be appropriately managed using a monitor subsystem. FIG. 1B illustrates a system 100a including a monitor subsystem 120 that can be utilized to manage requests from client sequencing applications on client subsystems 110a, 110b running on different versions of software. For example, the monitor subsystem 120 can receive a request 150 from client subsystem 110a and a request 152 from client subsystem 110b. Each of the client subsystems 110a, 110b can communicate with the monitor subsystem 120 through a standard Berkley (BSD) socket, an address (e.g., an IP address and port), or another communication interface that can be accessed via function calls as an endpoint for sending and / or receiving information. The client subsystems 110a, 110b may be running sequencing applications running on different versions of software. The monitor subsystem 120 may be a daemon or other background process running on one or more server devices 102, one or more sequencing devices 114, one or more client devices 108, and / or distributed across the server devices 102, sequencing devices 114, and / or client devices 108. The monitor subsystem 120 may manage requests 150, 152 for services performed by the server subsystem 104 and may enable the server subsystem 104 to load and execute different versions of software for operating the sequencing system to support the services in each of the requests 150, 152.

[0026] Each request 150, 152 may include a version identifier, product identifier, or other information associated with the respective client subsystem 110a, 110b and / or sequencing application from which each request 150, 152 was received. The monitor subsystem 120 may use the version identifier, product identifier, and / or other information in the request 150 to identify the version that the client subsystem 110a is utilizing for operation of the sequencing application executing thereon. The monitor subsystem 120 may use the version identifier, product identifier, and / or other information in the request 152 to identify the version that the client subsystem 110b is utilizing for operation of the sequencing application executing thereon.

[0027] The monitor subsystem 120 may be launched upon startup of the sequencing system and / or device on which it is installed. The monitor subsystem 120 may monitor the version of the sequencing system installed on the server subsystem 104 (which may be referred to as the server subsystem 104 version) to determine whether the version of the sequencing system installed on the server subsystem 104 is compatible with the version of the application running on the client subsystems 110a, 110b and / or the client subsystem on which the request 150, 152 is received. The compatible version may be stored in a file in memory for reference by the monitor subsystem 120. When an updated version of the sequencing system is installed in memory on one or more devices on which the server subsystem is installed, the file may be updated to identify a compatible version of the client subsystem. The monitor subsystem 120 may communicate with one or more processes on the server subsystem 104 to identify the version of one or more layers of software and / or hardware installed on the sequencing system. For example, the server subsystem 104 may program each layer of software and / or hardware in a vertical solution stack according to a different version of the sequencing system.

[0028] In one example, the software layer of the server subsystem 104 may include a daemon process 160 with which the monitor subsystem 120 may communicate. The daemon process 160 may be a background process running on one or more devices (e.g., the server device 102, the sequencing device 114, and / or the client device 108). The daemon process 160 may manage the hardware on one or more devices (e.g., the server device 102, the sequencing device 114, and / or the client device 108) in response to requests from client subsystems running compatible versions of the sequencing application. The daemon process 160 may be a child service of the monitor subsystem 120 launched by the monitor subsystem 120. The monitor subsystem 120 may launch and monitor its child processes for the duration of its execution. If any child process terminates unexpectedly, the monitor subsystem 120 can detect the loss and restart the child process. Monitor subsystem 120 can decompose and construct services for each layer during a version switch by sending commands to one or more child processes (e.g., daemon process 160, daemon license process 163, and / or daemon process 164). Monitor subsystem 120 can query daemon process 160 about the versions of software and / or hardware layers in the vertical solution stack. In another example, monitor subsystem 120 can receive push notifications of the versions of software and / or hardware layers in the vertical solution stack.

[0029] The server subsystem 104 may include other software processes. For example, the server subsystem 104 may include other background daemon processes in the vertical solution stack. The server subsystem 104 may include a daemon license process 163. The daemon license process 163 may communicate with the monitor subsystem 120 and / or the daemon process 160 to regulate licenses used by the server subsystem 104. For example, the daemon process 160 may cooperate with the daemon license process 163 to validate licenses on behalf of the client subsystem 110. The monitor subsystem 120 may launch the daemon process 160 and / or the daemon license process 163 and monitor these services as described herein. The server subsystem 104 may also, or alternatively, include a daemon huge page process 164. The daemon huge page process 164 may communicate with the daemon process 160 and / or the huge page control process 166 to manage huge pages used for direct memory access (DMA) transfers between host memory and external hardware (e.g., external FPGA hardware). For example, daemon process 160 may coordinate with daemon huge page process 164 on behalf of client subsystem 110. Monitor subsystem 120 may launch daemon process 160 and / or huge page process 164 and monitor these services as described herein. Daemon license process 163 and daemon huge page process 164 may be child services of monitor subsystem 120 that are launched by monitor subsystem 120.

[0030] The server subsystem 104 may include a loadable kernel driver 162. For example, the loadable kernel driver 162 may be included in a vertical solution stack. The loadable kernel driver 162 may be a memory-resident application for facilitating interaction between one or more pieces of hardware and one or more pieces of software. For example, the loadable kernel driver 162 may communicate with the daemon process 160 and / or one or more pieces of programmable hardware for servicing the sequencing system. The loadable kernel driver 162 may support one or more field-programmable gate arrays (FPGAs) with partial reconfiguration bitstream 168. For example, the loadable kernel driver 162 may support one or more FPGAs via a Peripheral Component Interconnect Express (PCIe) or another type of serial expansion bus for connecting to one or more peripheral devices.

[0031] The hardware layer within the server subsystem 104 may include programming for one or more hardware layers in a vertical solution stack, such as an FPGA with a partially reconfigurable bitstream 168 and / or a shell 170. The shell 170 may be a hardware layer containing low-level code for controlling hardware functions on one or more devices on which the server subsystem 104 is running (e.g., the server device 102, the sequencing device 114, and / or the client device 108). The FPGA may contain higher-level code, such as a partially reconfigurable bitstream 168, for controlling bioinformatics components of the sequencing system. Different sequencing features may be utilized to service requests to the sequencing system by the server subsystem 104 uploading different bioinformatics components to the partially reconfigurable bitstream 168 of the FPGA. For example, different images of the partially reconfigurable bitstream 168 may be uploaded to perform different secondary and / or tertiary forms of sequencing analysis. Different sequencing features may be utilized to service requests to the sequencing system by server subsystems 104 that upload different versions of bioinformatics components via FPGA partial reconfiguration bitstreams 168. Different sequencing features may include different algorithms and / or optimization improvements to other versions. Each server subsystem 104 may include one or more FPGAs, each of which may be independently partially reconfigured with custom hardware and / or its own shell 170 for board management.

[0032] FIG. 1C illustrates an example of one or more bioinformatics subsystems that may be implemented by a sequencing system operating on the server subsystem 104 to perform secondary and / or tertiary forms of sequencing analysis. As shown in FIG. 1C, the sequencing system may implement a mapper subsystem 122, a sorter subsystem 124, and / or a variant caller subsystem 126. Each bioinformatics subsystem may perform a different sequencing task. The mapper subsystem 122 may be implemented to align reads within sequencing data received from the sequencing device 114 and / or stored on one or more devices on which the server subsystem 104 is operating (e.g., the server device 102, the sequencing device 114, and / or the client device 108). The reads within the sequencing data generated by the sequencing device 114 and / or generated and stored in a file in memory may not be included in a single sequence having all DNA information. Instead, the sequencing data generated by the sequencing device 114 and / or generated in a file stored in memory may include several short subsequences or reads having partial DNA information. Read alignment may be performed by the mapper subsystem 122 to map the reads to a reference genome and identify the location of each individual read on the reference genome.

[0033] After read alignment is performed in the mapper subsystem 122, the aligned sequencing data may be passed downstream to the sorting subsystem 124 to sort the reads by reference position, and polymerase chain reaction (PCR) or optical duplicates are optionally flagged. An initial sorting stage may be performed by the sorter subsystem 124 on the aligned reads returning from RAM 125. Once mapping is complete, final sorting and duplicate marking may begin.

[0034] The variant caller subsystem 126 can be used to call variants from aligned and sorted reads in sequencing data. For example, the variant caller subsystem can receive a sorted BAM file as input and process the reads to generate variant data contained in a variant call file (VCF) or genomic variant call format (gVCF) file as output from the variant caller subsystem 126.

[0035] For each of the subsystems (e.g., mapper subsystem 122, sorter subsystem 124, and variant caller subsystem 126), different images can be loaded from disk 123 into random access memory (RAM) 125 on server device 102. For example, RAM 125 can comprise a field programmable gate array (FPGA) board dynamic RAM (DRAM) on server device 102 into which different images are loaded from disk 123 to perform different types of analysis using the corresponding subsystem.

[0036] To support bioinformatics analysis according to different versions of the server subsystem 104 that handle requests from the client subsystems 110a, 110b, different versions of the subsystems can be loaded into RAM 125. Referring again to Figure 1B, different versions of each subsystem can be loaded into the FPGA as partial reconfiguration bitstreams 168 to enable the server subsystem 104 to perform analysis according to different bioinformatics subsystems (e.g., mapper subsystem 122, sorter subsystem 124, and variant caller subsystem 126).

[0037] 1B , daemon process 160 can receive requests from authorized client subsystems 110 a, 110 b and communicate with other daemon processes 163, 164 and / or loadable kernel driver 162 to update partial reconstruction bitstream 168 to perform sequencing analysis in response to the request. The request can be authorized by monitor subsystem 120 when monitor subsystem 120 determines that the request is received from client subsystem 110 a running a sequencing application having a version compatible with the current version of server subsystem 104. The version of server subsystem 104 can be updated by updating the versions of one or more components of server subsystem 104. For example, the version of server subsystem 104 can be updated by updating one or more layers of a vertical solution stack, which can include daemon process 160, daemon license process 163, daemon process 164, huge page control process 166, loadable kernel driver 162, partial reconstruction bitstream 168, and / or shell 170.

[0038] The monitor subsystem 120 may send commands to the daemon process 160 to start, stop, and / or restart one or more processes, drivers, and / or layers. The monitor subsystem 120 may also send commands to the daemon process 160 to cause the daemon process 160 to select a version of the sequencing system and load it into memory to run on the server subsystem 104. The monitor subsystem 120 may send commands to the daemon process 160 to load a version of the loadable kernel driver 162 and / or load a version of the huge page control process 166.

[0039] The monitor subsystem 120 can be responsible for allowing the client subsystems 110a, 110b to transmit requests 154, 156 to the daemon process 160. When the server subsystem 104 implements a version of the sequencing system that is compatible with the version of the sequencing application executing on the client subsystem 110a, 110b on which the request 150, 152 was received, the monitor subsystem 120 can allow the client subsystem 110a, 110b to transmit the request 154, 156 to the daemon process 160. The request 150, 152 can be triggered by a call from higher-level software that can provide the full path or a standard script that can determine the path from the version number of the sequencing application. The trigger can cause the request 150, 152 to be sent to the monitor subsystem 120 to request permission to continue execution. The request 150, 152 can block the call, returning when permission is obtained or denied. Each request 150, 152 may include a product identifier, a version identifier, and / or other information associated with the respective client subsystem 110a, 110b from which the request 150, 152 was received. From the information in the request 150, 152, the monitor subsystem 120 may determine whether to allow the client subsystem 110a, 110b to access the daemon process 160.

[0040] In one example, client subsystem 110a and client subsystem 110b may be running sequencing applications using different versions. Monitor subsystem 120 may receive request 150 from client subsystem 110a and determine that client subsystem 110a is running a sequencing application having a version compatible with the current version of the sequencing system running on server subsystem 104. Monitor subsystem 120 may authorize client subsystem 110a to send request 154 to daemon process 160 to access daemon process 160 and / or to have the request serviced by server subsystem 104. If monitor subsystem 120 determines that the version of client subsystem 110a on which request 150 was received is compatible with the version of server subsystem 104, monitor subsystem 120 may send authorization message 151 to client subsystem 110a granting access to server subsystem 104 and / or daemon process 160. The authorization message may include an acknowledgment in response to the request, or monitor subsystem 120 may send an acknowledgment of receipt of each request without providing authorization. The authorized client subsystem 110a may be registered in the memory of the monitor subsystem 120 as being authorized to be serviced by the server subsystem 104. The authorization message 151 may include an access key for accessing the server subsystem 104 and / or the daemon process 160. The access key may also be provided to the daemon process 160 in a notification message notifying the daemon process 160 that the client subsystem 110a has been authorized, so that the daemon process 160 can identify the authorized client subsystem 110a. In another example, the monitor subsystem 120 may provide the daemon process 160 with an identifier for the client subsystem 110a or other information associated with the client subsystem 110a to indicate that the client subsystem 110a has been authorized.Daemon process 160 receives request 154 and may identify that the request is received from an authorized client subsystem 110a (e.g., based on an access key or other information in request 154). After daemon process 160 identifies that request 154 is received from an authorized client subsystem 110a, daemon process 160 may establish a connection with client subsystem 110a, register client subsystem 110a in memory, and begin servicing request 154 by communicating with other processes, drivers, and / or layers of the vertical solution stack within server subsystem 104. The connection may be established through a standard Berkley (BSD) socket or another communication interface, an address (e.g., an IP address and port), or another communication interface that may be accessed via function calls as an endpoint for sending and / or receiving information.

[0041] The daemon process 160 can communicate with the loadable kernel driver 162 to service one or more requests from the client subsystems. For example, the loadable kernel driver 162 can have one or more FPGAs under its control. The loadable kernel driver 162 can support one or more FPGAs via PCIe. A bioinformatics subsystem (e.g., the mapper subsystem 122, the sorter subsystem 124, and the variant caller subsystem 126) can be loaded into each FPGA to process requests. To process different requests simultaneously, different bioinformatics subsystems can be loaded into different FPGAs. Thus, parallel processing across multiple FPGAs can be used to process requests in batches. Each of the bioinformatics subsystems may be running a version compatible with the version of the request from the client subsystem. Workload management and dispatching of client jobs to FPGAs can be performed by the daemon process 160 after receiving the corresponding request. The loadable kernel driver 162 can enumerate devices and provide a communication path between the daemon process 160 and the appropriate FPGA.

[0042] The monitor subsystem 120 may receive a request 152 from the client subsystem 110b and determine that the client subsystem 110b is running a sequencing application having a version that is incompatible with the current version of the sequencing system running on the server subsystem 104. Because the client subsystem 110b is running a sequencing application having a version that is incompatible with the current version of the server subsystem 104, the client subsystem 110b may be blocked and / or the request 152 may be queued for servicing at a later time. Requests that are compatible with a different version of the server subsystem than the one currently loaded may be placed in a different queue or in the same queue. The client subsystem 110b may be blocked and / or the request 152 may be queued until the sequencing system of the server subsystem 104 is running a version that is compatible with the version of the sequencing application running on the client subsystem 110b. The monitor subsystem 120 may be unable to provide the client subsystem 110b with an access key that prevents the client subsystem 110b from accessing the daemon process 160 of the server subsystem 104 until the server subsystem 104 is running a version of the sequencing application that is compatible with the version running on the client subsystem 110b. The monitor subsystem 120 may send a message to the client subsystem configured to cause the client subsystem to wait for permission and / or transmit a subsequent request at a later time.

[0043] The monitor subsystem 120 may monitor the status of the server subsystem 104 to determine the appropriate time to allow the client subsystem 110b to access the server subsystem 104. For example, the monitor subsystem 120 may monitor the status of client subsystems, such as the client subsystem 110a, that are authorized and / or registered in memory as authorized to access the server subsystem 104. The monitor subsystem 120 may monitor the status of one or more child processes (e.g., the daemon process 160, the daemon license process 163, and / or the daemon process 164) that are handling requests from client subsystems authorized to access the server subsystem 104 and may identify a termination signal from one or more child processes servicing the client subsystem requests. The termination signal may identify the completion of a service requested from the server subsystem 104 (e.g., the completion of a service and / or task identified in the request 154) or an abnormal termination that prevented the requested service from completing. If any child process terminates without the monitor subsystem 120 explicitly signaling the child process to be stopped, the monitor subsystem 120 may be notified of the child process termination by another service. For example, monitor subsystem 120 may receive PIDs (process identifiers) and termination causes from other services running on the same device. Monitor subsystem 120 may record the PIDs and / or termination causes and restart the processes. If monitor subsystem 120 identifies an abnormal termination, monitor subsystem 120 may automatically reset software and / or hardware managed by server subsystem 104. For example, monitor subsystem 120 may send a signal to daemon process 160 to cause daemon process 160 to reset hardware, child processes of monitor subsystem 120, processes, drivers, and / or other software in the vertical solution stack.The hardware and / or software may be rebooted to operate with the same version of software that was loaded into the server subsystem 104 before the reboot. After the hardware and / or software is rebooted, the server subsystem 104 can continue to service requests that are compatible with the current version of the server subsystem 104.

[0044] The server subsystem 104 may be operating in an active state when one or more processes therein are servicing requests from authorized client subsystems, such as client subsystem 110a. While the server subsystem 104 is in an active state and servicing requests 154 from client subsystem 110a, the monitor subsystem 120 may continue to receive requests from other client subsystems. Requests from client subsystems running a sequencing application in a version incompatible with the server subsystem 104 may continue to be blocked and / or queued for later servicing. Requests from client subsystems running a sequencing application in a version compatible with the server subsystem 104 may continue to be authorized (e.g., while request 152 from client subsystem 110b is queued), and the server subsystem 104 may remain in the active state until a termination signal is identified. Upon termination of the active state of each previously authorized client subsystem, the server subsystem 104 and / or one or more processes therein may enter an idle state.

[0045] The monitor subsystem 120 may communicate with one or more processes of the server subsystem 104 to determine whether the server subsystem 104 and / or one or more processes therein are in an active or idle state. In one example, the monitor subsystem 120 may communicate with a daemon process 160 to determine the active and idle states of the server subsystem 104 and / or one or more processes therein. The monitor subsystem 120 can send commands to the daemon process 160 to request the current status of the processing of each request from a client subsystem. The monitor subsystem 120 can send commands to the daemon process 160 to query the current version of the server subsystem 104.

[0046] Monitor subsystem 120 may determine from daemon process 160 when daemon process 160 and / or other processes or layers in the vertical solution stack are active or idle. If monitor subsystem 120 determines from daemon process 160 that daemon process 160 and / or other processes or layers in the vertical solution stack have stopped serving client subsystems and entered an idle state for a period of time, monitor subsystem 120 may change the version of the sequencing system being run by server subsystem 104 and allow requests from client subsystems running sequencing applications according to a compatible version.

[0047] The monitor subsystem 120 can select the next version of the sequencing system. The monitor subsystem 120 can select the next version of the sequencing system in response to user input from the client device 108. The user input can identify the selected version of the server subsystem. The user input can be sent in response to a query from the monitor subsystem 120. The monitor subsystem 120 can automatically select the next version based on a version in a request previously received from a client subsystem. The monitor subsystem 120 can select a version based on a version in a first blocked and / or queued request. For example, the monitor subsystem 120 can select a version of the server subsystem 104 to be loaded into memory that is compatible with a version identified in a request 152 received from client subsystem 110b that was previously determined to be incompatible. The monitor subsystem 120 can continue to select versions based on the order of blocked and / or queued requests. The monitor subsystem 120 can select a version based on the number of blocked and / or queued requests. For example, the monitor subsystem 120 can select the next version to be loaded into memory of the server subsystem 104 by identifying the version that is compatible with the greatest number of blocked or queued requests from the client subsystem.

[0048] The monitor subsystem 120 may communicate with one or more processes of the server subsystem 104 to orchestrate changes in the version of the sequencing system running on the server subsystem 104. In one example, the monitor subsystem 120 may communicate with the daemon process 160 to restart one or more pieces of hardware and / or software to change the version of the server subsystem 104. One or more layers (e.g., each layer) of the vertical solution stack of the server subsystem 104 may be disassembled and rebuilt for the next version. The monitor subsystem 120 may send commands to the daemon process 160 to cause the daemon process to remove one or more processes, drivers, and / or layers currently loaded in memory. The commands from the monitor subsystem 120 may be received by one or more child processes (e.g., the daemon process 160) to cause one or more layers to disassemble the current version of a service by stopping the services that support the current version before switching to another version. The monitor subsystem 120 may send commands that are received by one or more child processes (e.g., the daemon process 160) to cause one or more layers to rebuilt to support the next version by restarting the next version of the service. For example, monitor subsystem 120 may send one or more commands to one or more child processes (e.g., daemon process 160) in communication with one or more other layers of the vertical solution stack to decompose and recompose the services supported by each layer. One or more child processes (e.g., daemon process 160) may reset the FPGA and / or load new programmable hardware into the FPGA to enable a complete solution including hardware and / or software version changes.

[0049] The processes, drivers, and / or layers to be disassembled and / or reassembled when changing versions may be predefined or may be dynamically selected. For example, the monitor subsystem 120 may select the processes, drivers, and / or layers to be disassembled and / or reassembled based on the previous and next versions of the server subsystem 104. Each version of the sequencing system may be stored in memory along with a version file that can be accessed by the monitor subsystem 120 to identify the portions of the server subsystem 104 to be disassembled and / or reassembled to support the next version of the sequencing system being operated by the server subsystem 104. Each version of the sequencing system may include metadata or other information that can be read by the monitor subsystem to select the processes, drivers, and / or layers of the vertical solution stack to load into memory. For example, each version of the sequencing system may provide a manifest that can be used by the monitor subsystem 120 to select the processes, drivers, and / or layers to load into memory for each version. Each manifest may include a version number corresponding to the version of the sequencing system for which the manifest is provided. The manifest may include the manifest version itself, as each manifest may have a different version. The manifest may include the versions of one or more processes and / or drivers to be loaded into memory to build the vertical solution stack. For example, the manifest may include the version of daemon process 160, the version of daemon license process 163, and / or the version of daemon huge page process 164 to support the version of server subsystem 104. The manifest may include the driver version and / or location of the kernel object for loadable kernel driver 162. For example, the location of the kernel object may include the version directory or an alternate location (e.g., when multiple versions of a kernel driver are supported).The manifest may include a version of the client subsystem and / or a sequencing application running on the client subsystem that is compatible with the version of the server subsystem 104. The manifest may include a version of the partially reconstructed bitstream 168 and / or subsystems that may be loaded therein (e.g., the mapper subsystem 122, the sorter subsystem 124, and / or the variant caller subsystem 126). The manifest may include a version of the shell 170. Some processes, drivers, and / or layers may remain static from version to version, which may support backward compatibility with legacy systems. For example, the loadable kernel driver 162 and / or the shell 170 may remain static between versions to support processes in other layers of the vertical solution stack.

[0050] After monitor subsystem 120 selects a version of the sequencing system being run by server subsystem 104 and loads processes, drivers, and / or layers for the selected version of the sequencing system, processes may be started and / or drivers may be loaded into the vertical solution stack to service requests compatible with the selected version of the sequencing system. In one example, if monitor subsystem 120 determines that the version of the sequencing system running on server subsystem 104 is compatible with the version of the sequencing application of client subsystem 110b, monitor subsystem 120 may allow client subsystem 110b to access server subsystem 104 and / or one or more processes thereon. Monitor subsystem 120 may allow client subsystem 110b to send request 156 to daemon process 160 to access daemon process 160 and / or to have the request serviced by server subsystem 104. After the monitor subsystem 120 determines that the version of the client subsystem 110b on which the request 152 was received is compatible with the version of the server subsystem 104, the monitor subsystem 120 may send an authorization message 153 to the client subsystem 110b granting access to the server subsystem 104 and / or the daemon process 160. The authorization message may include an acknowledgment in response to the request, or the monitor subsystem 120 may send an acknowledgment of receipt of each request without providing authorization. The authorized client subsystem 110b may be registered in the memory of the monitor subsystem 120 as being authorized to be serviced by the server subsystem 104. The authorization message 153 may include an access key for accessing the server subsystem 104 and / or the daemon process 160.The access key may also be provided to the daemon process 160 in a notification message notifying the daemon process that client subsystem 110b has been authorized, so that the daemon process 160 can identify the authorized client subsystem 110b. In another example, the monitor subsystem 120 may provide the daemon process 160 with an identifier for the client subsystem 110b or other information associated with the client subsystem 110b to indicate that the client subsystem 110b has been authorized. The daemon process 160 may receive the request 156 and identify that the request has been received from an authorized client subsystem 110b (e.g., based on the access key or other information in the request 156). After the daemon process 160 identifies that the request 156 has been received from an authorized client subsystem 110b, the daemon process 160 may establish a connection with the client subsystem 110b, register the client subsystem 110b in memory, and begin servicing the request 156 by communicating with other processes, drivers, and / or layers of the vertical solution stack within the server subsystem 104. For example, daemon process 160 may communicate with its clients using an inter-process communication (IPC) messaging protocol over a BSD socket. Each client may register with daemon process 160 by connecting to a Unix domain socket address. This channel may be open for clients to send messages to daemon process 160, which may respond after daemon process 160 completes the client's request.

[0051] 2 is a flowchart illustrating an example procedure 200 for monitoring the version of a server subsystem and processing requests from compatible client subsystems. One or more portions of procedure 200 may be performed by one or more computing devices or systems. For example, one or more portions of procedure 200 may be performed by one or more server devices, one or more sequencing devices, and / or one or more client devices. One or more portions of procedure 200 may be stored in memory as computer-readable or machine-readable instructions that may be executed by a processor of one or more computing devices. One or more portions of procedure 200 may be performed by one or more subsystems operating on the client devices, sequencing devices, and / or server devices. For example, one or more portions of the procedure may be performed by a client subsystem, a server subsystem, and / or a monitor subsystem, as described herein. While portions of procedure 200 may be described herein as being performed by a monitor subsystem, procedure 300 or portions thereof may be performed by another subsystem operating on a computing device or distributed across multiple computing devices, such as one or more client computing devices, one or more sequencing devices, and / or one or more server computing devices.

[0052] The procedure 200 may begin at 202. As shown in FIG. 2 , at 202, a monitor subsystem may receive one or more requests from one or more client subsystems. The requests may be received individually or in batches to be processed by a sequencing system of a server subsystem. The requests may include a product identifier, a version identifier, and / or other information associated with the client subsystem from which the request was received. At 204, the monitor subsystem may determine a version associated with the client subsystem from which the request was received. For example, the monitor subsystem may determine the version based on the product identifier, the version identifier, or other information associated with the client subsystem. At 206, the monitor subsystem may determine whether the version associated with the server subsystem is compatible with the version associated with the client subsystem. For example, the monitor subsystem may receive an indication of the version of the sequencing system running on the server subsystem to determine whether the version of the sequencing system is compatible with the version of the sequencing application running on the client subsystem. The indication of the version of the sequencing system running on the server subsystem may be received from a daemon process running on the server subsystem (e.g., in response to a request). Compatible versions may be indicated by the same version number / identifier or a different version number / identifier indicated in memory as being compatible with one or more features of another version number / identifier. A version may be a version of one or more processes, drivers, and / or layers of a vertical solution stack. If the version associated with the server subsystem is compatible with the version associated with the client subsystem, the client subsystem may be granted access to the server subsystem and / or one or more processes thereon to process the request, at 210.The request may be processed by loading one or more bioinformatics subsystems (e.g., a mapper subsystem, a sorter subsystem, and / or a variant caller subsystem) into one or more FPGAs to perform secondary and / or tertiary analysis of the sequencing data.

[0053] If the version associated with the server subsystem is incompatible with the version associated with the client subsystem, the monitor subsystem may cause the client subsystem to wait to process the request at 208. For example, the monitor subsystem may block the request to prevent access to the server subsystem and / or queue the request for later processing. The monitor subsystem may determine at 212 whether additional requests are received while the server subsystem is operating its sequencing system at its current version. For example, additional requests may continue to be received by the monitor subsystem while the server subsystem is processing one or more requests from the client subsystem that were granted access at 210 and / or before the server subsystem changes versions. If additional requests are received by the monitor subsystem at 212, the requests may be processed at 204 to determine the version associated with the client subsystem to determine whether to grant access to the requests at 210. The monitor subsystem may determine at 214 whether the server subsystem is idle. A server subsystem may be determined to be idle when one or more processes operating the sequencing system thereon are determined to be idle. The monitor subsystem may request the status of one or more processes of the server subsystem. In one example, the monitor subsystem can send messages to a daemon process of the server subsystem to determine the status of processing requests from the client subsystems. The daemon process can send a termination signal at the end of processing requests from one or more client subsystems. The monitor subsystem can monitor the status of the requests and identify the termination signal for each previously granted request.If it is determined that the server subsystem is still active and processing requests from the client subsystem, the monitor subsystem may monitor for additional requests at 212 and / or continue to monitor the server subsystem to identify idle conditions at 214.

[0054] If the server subsystem and / or one or more processes running thereon are determined to be idle, the monitor subsystem may determine at 215 whether to change the version associated with the server subsystem. The monitor subsystem may identify an instruction for changing the version associated with the server subsystem before making the change. For example, the monitor subsystem may determine to change the version associated with the server subsystem if additional requests are received from a client subsystem associated with a blocked and / or queued incompatible version. The monitor subsystem may also, or alternatively, determine to change the version associated with the server subsystem if user input is received from a sequencing application running on a client device instructing the monitor subsystem to change the version of the server subsystem. If the monitor subsystem determines to maintain the version associated with the server subsystem (e.g., because an instruction for changing the version associated with the server subsystem is not identified), procedure 200 may end.

[0055] If the monitor subsystem determines to change the version associated with the server subsystem, the monitor subsystem may cause the server subsystem to change the version at 216 to process requests from client subsystems that are compatible with another version of the server subsystem. The monitor subsystem may send a command to the server subsystem and / or one or more processes running thereon to cause the server subsystem to stop execution of one or more processes before changing the version. The monitor subsystem may send a command to the server subsystem and / or one or more processes running thereon to cause the server subsystem to change the version for processing requests from the client subsystem. The command may be sent to a daemon process running on the server subsystem to change the version of one or more processes, drivers, and / or layers of the vertical solution stack in accordance with the next version. The next version may be selected by the monitor subsystem. For example, the next version may be selected based on user input received from a client device running a sequencing application. The next version may also, or alternatively, be selected automatically based on the versions of previously blocked and / or queued requests from the client subsystem. The monitor subsystem may select a version based on the version in the first blocked and / or queued request or the order of blocked and / or queued requests in time. The monitor subsystem may select a version based on the number of blocked and / or queued requests. For example, the monitor subsystem may select the next version to be loaded into the server subsystem's memory by identifying the version that is compatible with the greatest number of blocked and / or queued requests from the client subsystem.

[0056] After the version associated with the server subsystem is changed to the next version, the monitor subsystem may send a command to the server subsystem and / or one or more processes (e.g., daemon processes) thereon to begin execution. At 218, the monitor subsystem may determine whether any previous blocked and / or queued requests have been received for processing by the server subsystem. If no previous requests have been received for processing by the server subsystem, the procedure 200 may end. If any blocked and / or queued previous requests have been received, the monitor subsystem may determine at 204 whether the versions of one or more previous requests are compatible with the server subsystem. The monitor subsystem may send a message to the client subsystem to notify the client subsystem that the server subsystem is ready to service the request. The monitor subsystem may send a request for the client subsystem to resend the processed request. The monitor subsystem may grant access to process requests associated with client subsystems determined to be compatible at 210. The monitor subsystem may continue to block and / or queue requests that are incompatible with the current version associated with the server subsystem after the version is changed. After each of the requests has been processed as described herein, the procedure may end.

[0057] 3 is a block diagram illustrating an exemplary computing device 300 (or computing system). One or more computing devices, such as computing device 300, may implement one or more features for monitoring and / or modifying a version of a sequencing system to service requests from a sequencing application as described herein. For example, computing device 300 may comprise one or more of sequencing device 114, client device 108, and / or server device 102 shown in FIG. 1A. As illustrated by FIG. 3, computing device 300 may comprise a processor 302, memory 304, storage device 306, I / O interface 308, and communication interface 310, which may be communicatively coupled by a communication infrastructure 312. Computing device 300 may include fewer or more components than those shown in FIG. 3.

[0058] The processor 302 may include hardware for executing instructions, such as instructions that configure a computer application or system. In an example, to execute instructions to operate as described herein, the processor 302 may retrieve (or fetch) instructions from an internal register, an internal cache, memory 304, or storage device 306, decode, and execute these instructions. The memory 304 may be volatile or non-volatile memory used to store data, metadata, computer-readable or machine-readable instructions, and / or programs for execution by the processor to operate as described herein. The storage device 306 may include storage, such as a hard disk, flash disk drive, or other digital storage device, for storing data or instructions to perform the methods described herein.

[0059] The I / O interface 308 may enable a user to provide input to, receive output from, and / or otherwise transfer data to and receive data from the computing device 300. The I / O interface 308 may include a mouse, a keypad or keyboard, a touchscreen, a camera, an optical scanner, a network interface, a modem, other known I / O devices, or a combination of such I / O interfaces. The I / O interface 308 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., a display driver), one or more audio speakers, and one or more audio drivers. The I / O interface 308 may be configured to provide graphical data to a display for presentation to a user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content.

[0060] Communications interface 310 may include hardware, software, or both. In any case, communications interface 310 may provide one or more interfaces for communication (e.g., packet-based communication, etc.) between computing device 300 and one or more other computing devices or networks. The communication may be wired or wireless. By way of example and not limitation, communications interface 310 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wired-based network, or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network such as Wi-Fi.

[0061] Additionally, the communication interface 310 can facilitate communication with various types of wired or wireless networks. The communication interface 310 can also facilitate communication using various communication protocols. The communication infrastructure 312 can also include hardware, software, or both that couple components of the computing device 300 to one another. For example, the communication interface 310 can use one or more networks and / or protocols to enable multiple computing devices connected by a particular infrastructure to communicate with each other to perform one or more aspects of the processes described herein. By way of example, a sequencing process can enable multiple devices (e.g., a client device, a sequencing device, and a server device) to exchange information such as sequencing data and error notifications.

[0062] In addition to what is described herein, the methods and systems may also be implemented in, for example, a computer program, software, or firmware embodied in one or more computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and tangible / non-transitory computer-readable storage media. Examples of tangible / non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), removable disks, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

[0063] While the present disclosure has been described with respect to particular embodiments and generally associated methods, modifications and permutations of the embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of exemplary embodiments does not constrain the present disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of the present disclosure. [Explanation of symbols]

[0064] 100 System Environment 102 Server Device 104 Server Subsystem 108 client devices 110, 110a, 110b Client Subsystem 112 Network 114 Sequencing Device 116 databases 120 Monitor Subsystem 122 Mapper Subsystem 123 discs 124 Sorter Subsystem 125 Random Access Memory (RAM) 126 Variant Cola Subsystem 150,152 requests 151,153 permission messages 154,156 requests 160 daemon processes 162 Loadable Kernel Drivers 163 daemon license processes 164 daemon huge page processes 166 Huge Page Control Process 168 Partially Reconstructed Bitstream 170 shells 300 computing devices 302 processor 304 memory 306 Storage 308 I / O interface 310 Communication Interface 312 Communications Infrastructure

Claims

1. 1. A system comprising: at least one memory having computer readable instructions stored therein; at least one processor; The at least one processor, in response to the computer-readable instructions, receiving a request from a client subsystem via a monitor subsystem, the request being a request to perform secondary or tertiary analysis of sequencing data, the request including a version associated with the client subsystem; determining a first version associated with a server subsystem to be implemented to service the request; determining that the version associated with the client subsystem is incompatible with the first version associated with the server subsystem currently implemented to service the request; in response to determining that the version associated with the client subsystem is incompatible with the first version associated with the server subsystem, preventing the server subsystem from being accessed by the client subsystem; identifying changes from the first version to a second version associated with the server subsystem; determining that the second version associated with the server subsystem is compatible with the version associated with the client subsystem; enabling the client subsystem to access the server subsystem to service the request.

2. the request from the client subsystem is a first request, the client subsystem is a first client subsystem, and the at least one processor, in response to the computer-readable instructions, receiving a second request from a second client subsystem via the monitor subsystem, the second request including a version associated with the second client subsystem; determining, while the server subsystem is operating at the first version, that the version associated with the second client subsystem is compatible with the first version associated with the server subsystem; 2. The system of claim 1, further configured to: enable the server subsystem to be accessed by the second client subsystem for the second request.

3. The at least one processor, in response to the computer-readable instructions, identifying the server subsystem as idle after processing each request from a client subsystem associated with a compatible version; The system of claim 1 , further configured to cause the server subsystem to perform the change from the first version to the second version.

4. The system of claim 1 , wherein each version of the server subsystem includes different features for bioinformatics components associated with processing different requirements for the secondary analysis or the tertiary analysis.

5. The system of claim 1 , wherein different bioinformatics components are utilized by loading the different bioinformatics components into one or more field programmable gate arrays (FPGAs).

6. The system of claim 1 , wherein the change from the first version to the second version includes decomposing and building at least one software layer in a vertical solution stack.

7. 7. The system of claim 6, wherein the first version and the second version support different bioinformatics components that are loaded into one or more FPGAs to support the same or different sequencing tasks.

8. The system of claim 7 , wherein the sequencing tasks include tasks performed for the secondary analysis or the tertiary analysis of the sequencing data.

9. 10. The system of claim 1, wherein the secondary analysis or the tertiary analysis comprises alignment, sorting, or variant calling based on the sequencing data.

10. The system of claim 1 , wherein the monitor subsystem is a daemon process.

11. 10. The system of claim 1, wherein the server subsystem is a daemon process, the server subsystem configured to manage hardware on the system to service sequencing applications running on one or more client subsystems.

12. 12. The system of claim 11, wherein the daemon process is one of a plurality of predefined daemon processes in the server subsystem.

13. the at least one processor is configured to prevent the server subsystem from being accessed by the client subsystem for the request; 2. The system of claim 1, wherein the at least one processor is further configured to prevent an access key from being transmitted to the client subsystem or a connection from being established between the client subsystem and the server subsystem.

14. the at least one processor is configured to enable the server subsystem to be accessed by the second client subsystem; the at least one processor: providing an access key to the second client subsystem via the monitor subsystem; 2. The system of claim 1, further comprising: being configured to notify the server subsystem via the monitor subsystem that the access key has been provided to the second client subsystem.

15. the at least one processor is configured to notify the server subsystem; The system of claim 14 , further comprising the at least one processor configured to provide the access key to the server subsystem.

16. The processor, via the computer readable instructions, receiving, via the first client subsystem, a message indicating that the first client subsystem has been blocked; 15. The system of claim 14, further configured to wait to receive an indication from the monitor subsystem via the first client subsystem that the request can be processed.

17. The processor, via the computer readable instructions, receiving the access key via the second client subsystem; The system of claim 14 , further configured to transmit a message to the server subsystem including the access key for establishing a connection with the server subsystem.

18. The processor, via the computer readable instructions, The system of claim 1 , further configured to send an acknowledgement to the client subsystem in response to the request.

19. The processor, via the computer readable instructions, The system of claim 1 , further configured to receive the request from the client subsystem via a socket and to grant access to the server subsystem through the socket via an access key.

20. The processor, via the computer readable instructions, monitoring, by said monitor subsystem, a signal from at least one child process; Detecting a terminal signal via the at least one child process; The system of claim 1 , further configured to automatically restart the at least one child process.

Images