US10467151B2 - Using shared memory to transport data between server processes - Google Patents

Using shared memory to transport data between server processes Download PDF

Info

Publication number
US10467151B2
US10467151B2 US15/695,745 US201715695745A US10467151B2 US 10467151 B2 US10467151 B2 US 10467151B2 US 201715695745 A US201715695745 A US 201715695745A US 10467151 B2 US10467151 B2 US 10467151B2
Authority
US
United States
Prior art keywords
shared memory
memory segment
data
chunks
usage information
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.)
Active, expires
Application number
US15/695,745
Other versions
US20190073316A1 (en
Inventor
Igor Sysoev
Valentin Bartenev
Nikolay Shadrin
Maxim Romanov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
F5 Inc
Original Assignee
NGINX Inc
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
Application filed by NGINX Inc filed Critical NGINX Inc
Priority to US15/695,745 priority Critical patent/US10467151B2/en
Assigned to NGINX, Inc. reassignment NGINX, Inc. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARTENEV, VALENTIN, ROMANOV, MAXIM, SHADRIN, NIKOLAY, SYSOEV, IGOR
Publication of US20190073316A1 publication Critical patent/US20190073316A1/en
Assigned to NGINX reassignment NGINX CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE'S REGISTERED OFFICE PREVIOUSLY RECORDED ON REEL 043492 FRAME 0602. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: ROMANOV, MAXIM, BARTENEV, VALENTIN, SHADRIN, NIKOLAY, SYSOEV, IGOR
Assigned to NGINX, Inc. reassignment NGINX, Inc. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 049831 FRAME: 0432. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: ROMANOV, MAXIM, BARTENEV, VALENTIN, SHADRIN, NIKOLAY, SYSOEV, IGOR
Priority to US16/601,180 priority patent/US11249923B1/en
Assigned to F5 NETWORKS, INC. reassignment F5 NETWORKS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NGINX, Inc.
Application granted granted Critical
Publication of US10467151B2 publication Critical patent/US10467151B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • G06F12/1027Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • G06F12/1009Address translation using page tables, e.g. page table structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65Details of virtual memory and virtual address translation

Definitions

  • This invention pertains in general to web server architectures and in particular to transporting data between server processes.
  • sockets may be used to transport data between the different address spaces.
  • using sockets can require a large number of copy operations to move data between address spaces of the different processes. It is computationally inefficient for the web server to engage in the many memory copy operations, which can lead to high memory utilization and high memory overhead requirements.
  • copy operations require extra resources, such as locking operations for worker processes that receive data from a router process. Therefore, the performance of the web server is impacted due to the large number of copy operations for transporting data in traditional web server architectures.
  • One aspect provides a computer-implemented method for dynamically sharing data from a first process to a second process by creating a shared memory segment, obtaining a file descriptor referencing the shared memory segment, and mapping the shared memory segment in an address space of the first process.
  • the file descriptor is sent to the second process.
  • Responsive to receiving the file descriptor the shared memory segment is mapped in an address space of the second process.
  • data from the first process is shared to the second process.
  • Another aspect provides a non-transitory computer-readable storage medium storing executable computer program instructions for dynamically sharing data from a first process to a second process.
  • the computer program instructions create a shared memory segment, obtain a file descriptor referencing the shared memory segment, and map the shared memory segment in an address space of the first process.
  • the file descriptor is sent to a second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.
  • Still another aspect provides a system for dynamically sharing data from a first process to a second process.
  • the system includes a computer processor and a non-transitory computer-readable storage medium storing executable computer program instructions that when executed by the computer processor perform actions including creating a shared memory segment, obtaining a file descriptor referencing the shared memory segment, and mapping the shared memory segment in an address space of a first process.
  • the file descriptor is sent to a second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.
  • FIG. 1 is a high-level block diagram of a computing environment supporting use of shared memory to transport data between processes of a web server, according to one embodiment.
  • FIG. 2 is a high-level block diagram illustrating a more detailed view of the web server architecture, according to one embodiment.
  • FIG. 3 is a high-level block diagram illustrating components of a shared memory manager according to one embodiment.
  • FIG. 4 is a flowchart illustrating steps performed to dynamically share data using a shared memory segment, according to one embodiment.
  • FIG. 5 illustrates components of an example machine able to read instructions to dynamically use shared memory segments to exchange data, according to one embodiment.
  • FIG. 1 is a high-level block diagram of a computing environment 100 supporting use of shared memory to transport data between processes of a web server 128 , according to one embodiment.
  • FIG. 1 illustrates multiple client devices 104 and a web server 128 connected by a network 116 . While only a few client devices 104 and one web server are shown in FIG. 1 , embodiments of the computing environment 100 can have many such entities connected to the network.
  • FIG. 1 uses like reference numerals to identify like elements.
  • a letter after a reference numeral, such as “ 140 a ,” indicates that the text refers specifically to the element having that particular reference numeral.
  • a reference numeral in the text without a following letter, such as “ 140 ,” refers to any or all of the elements in the figures bearing that reference numeral.
  • “ 140 ” in the text refers to reference numerals “ 140 a ” and/or “ 140 b ” in the figures.
  • a client device 104 is an electronic device used by a user to perform functions such as consuming digital content, executing software applications, browsing web sites hosted by or otherwise interacting with the web server 128 on the network 116 , and downloading files.
  • the client device 104 may be a smartphone or a tablet, notebook, or desktop computer.
  • the client device 104 may be an Internet-of-Things (IoT)-connected device such as a home appliance, or even another web server.
  • the client device 104 may include a display device on which the user may view digital content stored on the client device 104 or downloaded from the web server 128 .
  • the client device 104 may include a user interface (UI), such as physical and/or on-screen buttons, with which the user may interact to perform functions such as consuming digital content, obtaining digital content, and transmitting digital content.
  • UI user interface
  • a client device 104 sends requests 108 to the web server 128 via the network 116 .
  • a request 108 seeks to access a resource maintained, controlled, or otherwise accessible by the web server 128 .
  • the client device 104 sends the request 108 using the Hypertext Transfer Protocol (HTTP) or a secure variant thereof.
  • HTTP Hypertext Transfer Protocol
  • a web browser on the client device 104 may send a request 108 to the web server 128 to post or fetch a file (e.g., a web page or an image).
  • the request 108 includes information identifying the requested resource and may also include information identifying the content to be posted, the client device 104 , the server 128 , and the session.
  • the network 116 enables communications among the client devices 104 and the web server 128 .
  • the network 116 receives requests 108 and corresponding data (e.g., contents of a file to be posted on a web page) from client devices 104 and forwards the requests 120 to the web server 128 .
  • the network 116 receives responses 124 and corresponding data (e.g., an image to be downloaded from a web page) from the web server 128 and forwards the responses 112 to the client devices 104 .
  • the network 116 can comprise the Internet as well as mobile telephone networks.
  • the network 116 uses standard communications technologies and/or protocols.
  • the network 116 can include links using technologies such as Ethernet, 802.11, Long-Term Evolution (LTE), etc.
  • the networking protocols used on the network 116 can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), HTTP, the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc.
  • the data exchanged over the network 116 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc.
  • links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc.
  • SSL secure sockets layer
  • TLS transport layer security
  • VPNs virtual private networks
  • IPsec Internet Protocol security
  • the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
  • the web server 128 receives and processes requests 120 from the client devices 104 and sends responses 124 back to the requesting client devices 104 .
  • the requests 120 received by the web server 128 are typically associated with data.
  • the web server 128 may also obtain a requested data resource and send a response 124 providing the data resource back to the requesting client device 104 .
  • the data resource is typically a file or other data, such as a web page or component thereof.
  • Requests 120 received by the web server 128 are processed by one or more router modules 132 .
  • the router module 132 is a process that analyzes the requests 120 and routes the requests 120 to one or more workers 136 for further processing.
  • the workers 136 may be processes and/or threads executing within a process space. There may be multiple router modules 132 operating concurrently in order to support load balancing and other features. Upon processing the requests, the workers 136 send responses and data back to the router module 132 .
  • the router module 132 and workers 136 use shared memory segments 148 to share data related to the requests and responses generated therefrom.
  • the router module 132 uses one or more shared memory segments 148 a for each worker 136 with which the router communicates. These shared memory segments 148 a are used for unidirectional communications from the router module 132 to the worker 136 .
  • a worker 136 likewise uses one or more other shared memory segments 148 b to engage in unidirectional communications with the router module 132 .
  • the router module 132 and worker 136 use a pair of unidirectional sockets 140 a , 140 b to respectively send messages about the shared memory segments 148 .
  • the sockets 140 effectively serve as control channels using which the router module 132 and worker 136 can exchange control messages about the shared memory segments 148 .
  • shared memory segments 148 in this way allows the router module 132 and worker 136 to efficiently share data related to requests and responses.
  • the sharing entity can place the data to be shared in the shared memory segment 148 and the recipient entity can read the data directly from the shared memory segment.
  • This technique avoids the memory copy operations and additional overhead that would be incurred if the sockets were used to transport the shared data between the entities.
  • the technique is performed on web servers 128 having multiple router modules 132 and/or workers 136 .
  • this technique provides security and fault isolation by using discrete shared memory segments between each router module 132 and workers 136 . While this description refers to using shared memory segments between a router module 132 and a worker 136 , the techniques described herein can be used to share data between any two processes.
  • FIG. 2 is a high-level block diagram illustrating a more detailed view of the web server architecture 200 , according to one embodiment.
  • FIG. 2 illustrates the router module 132 and worker 136 of FIG. 1 .
  • FIG. 2 illustrates the pair of unidirectional sockets 140 a , 140 b and the shared memory segments 148 a , 148 b .
  • FIG. 2 likewise illustrates that the router 132 has an associated router address space 204 and the worker 136 has an associated worker address space 208 .
  • the router module 132 and worker 136 each include a shared memory manager 228 .
  • Other embodiments of the web server 128 can have different and/or other modules than the ones described here, and the functionalities can be distributed among the modules in a different manner.
  • the router module 132 supervises processing of requests from the client devices 104 .
  • an inbound request 120 with its corresponding data reaches the web server 128 , it is passed to the router module 132 .
  • the router module 132 analyzes the request 120 and routes the request and its corresponding data to workers 136 .
  • the router module 132 may perform load balancing to distribute requests 120 across multiple router threads to increase throughput and reduce latency.
  • the router module 132 may use routing policies to control the flow and assignment of requests.
  • the router module 132 uses the router address space 204 to store data related to its execution.
  • the shared memory manager 228 a in the router module 132 allocates a portion of the router's address space 204 as a shared memory segment 148 a .
  • the shared memory segment 148 a is portioned in a set of discrete chunks, with each chunk (e.g., chunk 212 ) holding a fixed amount of memory.
  • a portion of the shared memory segment 148 contains usage information 210 a indicating which of the chunks are currently holding shared data.
  • the usage information 210 a may be a bitmap with each bit corresponding to a chunk of the shared memory segment 148 and having a value indicating whether the corresponding chunk is being utilized to store data.
  • the shared memory manager 228 a also creates a socket 140 a from the router module 132 to the worker 136 .
  • the shared memory manager 228 a passes control messages about the shared memory segment 148 a to the worker 136 via the socket 140 a .
  • the control messages may indicate, for example, that a shared memory segment has been created or that shared data has been placed in a particular chunk of a shared memory segment.
  • the control messages may additionally instruct the worker 136 to perform a particular function with respect to the shared memory segment 148 a , such as updating the usage information to indicate that shared data has been consumed by the worker 136 .
  • the worker process 136 likewise has an associated worker address space 208 and shared memory manager 228 b .
  • the shared memory manager 228 b in the worker 136 allocates a shared memory segment 148 b in the worker address space 208 and creates a socket 140 b for passing control messages about the shared memory segment to the router module 132 .
  • the worker process's shared memory segment 148 b is functionally equivalent to the router module's shared memory segment 148 a.
  • Each shared memory manager 228 a , 228 b also functions to receive control messages sent by the other shared memory manager.
  • a shared memory manager 228 receives a message via a socket 140 indicating that a shared memory segment 148 has been created.
  • the shared memory manager 228 creates a corresponding shared memory segment in the local address space (i.e., in the address space of the entity in which the shared memory manager 228 is located).
  • the shared memory manager 228 reads data from the shared memory segment in response to additional control messages received via the socket.
  • FIG. 3 is a high-level block diagram illustrating components of a shared memory manager 228 according to one embodiment.
  • the shared memory manager 228 includes a socket manager 304 , a memory mapping module 308 , a data transport module 310 , and a usage manager 312 .
  • Other embodiments of the shared memory manager 228 can have different and/or other modules than the ones described here, and the functionalities can be distributed among the modules in a different manner.
  • the socket manager 304 performs socket-based communications for the shared memory manager 228 . These communications include transmitting control messages to other shared memory managers 228 and receiving control messages from the other shared memory managers.
  • the socket manager 304 interacts with the socket manager of another shared memory manager 228 to create a pair of unidirectional sockets 140 that together form a bidirectional communication channel.
  • the socket manager uses the pair of sockets 140 to send and receive control messages.
  • the socket manager 304 may establish and use a persistent pair of sockets for communications, or may open a socket on demand when necessary to send a control message, and then close the socket after sending the message.
  • the memory mapping module 308 manages shared memory segments for the shared memory manager 228 . This management includes creating shared memory segments in order to share data to other entities (e.g., to a router module 132 or to a worker 136 ) and sending control messages to instruct the other entities to create a corresponding shared memory segments.
  • the memory mapping module 308 may create multiple shared memory segments 148 to share data with a given entity. For example, the memory mapping module 308 may initially create one shared memory segment 148 , and then create additional segments as more shared memory is required.
  • the shared memory management includes receiving control messages from other entities including notifications that shared memory segments have been created, and creating a corresponding shared memory segment based on the notification.
  • the memory mapping module 308 creates a shared memory segment, obtains a file descriptor referencing the shared memory segment, and maps the shared memory segment in the local address space of the process in which the shared memory manager 228 is executing (i.e., in the router address space 204 or worker address space 208 ).
  • the memory mapping module 308 creates the shared memory segment using the Linux “memfd_create” system call. The system call returns a file descriptor referencing the shared memory segment.
  • the memory mapping module 308 maps the shared memory segment using the UNIX “mmap( )” system call. This system call establishes a mapping between the process's local address space and the shared memory segment.
  • the memory mapping module 308 interacts with the socket manager 304 to send a control message to the other entity with which the memory segment is to be shared.
  • the control message includes the file descriptor for the shared memory segment.
  • the memory mapping module 308 may also receive a control message including a file descriptor for a shared memory segment created by a different shared memory manager 228 . In this case, the memory mapping module 308 performs the mmap( ) call using the file descriptor in order to map the shared memory segment in the local address space that is shared with the corresponding memory segment in the other process's local address space.
  • a shared memory segment is partitioned into multiple chunks.
  • the chunks may be evenly-sized. For example, if a shared memory segment is one megabyte in size, it may be formed of eight 128 KB chunks. Alternatively, some or all of the chunks may be of different sizes.
  • the memory mapping module 308 that creates a shared memory segment may include information about the partitioning of the memory segment in the control messages sent to the entity with which the memory segment is shared.
  • the data transport module 310 transports data using shared memory segments.
  • a shared memory segment can be written and read by many sharing entities. However, in one embodiment a shared memory segment is used for only unidirectional data sharing. The entity that created the shared memory segment writes to the segment to send data to the other entity with which the memory segment is shared. Likewise, an entity reads from a shared memory segment created by another entity in order to receive data shared by the other entity.
  • the entity sharing the data writes the data to one or more chunks of one or more shared memory segments.
  • the router module 132 is sharing data with the worker 136 .
  • the router module 132 writes the data to be shared to a chunk (e.g., chunk 212 ) of the shared memory segment 148 a that is shared with the worker 136 .
  • the router module 132 may perform this write by writing the data to the address in the router module's local address space 204 corresponding to the location of the chunk in the shared memory segment 148 .
  • the data transport module 310 detects the write to the chunk within the shared memory segment 148 a , and notifies the entity with which the segment has been shared of the shared data. Specifically, the data transport module 310 uses the socket to send a control message to the other shared memory manager 228 .
  • the control message indicates that data has been written to the shared memory segment and identifies the chunk to which the data were written (e.g., by specifying the index of the chunk).
  • the data transport module 310 also detects when data has been shared by another entity. In this case, the data transport module 310 receives a control message via a socket, where the control message indicates that data has been written to a particular chunk of a shared memory segment. The data transport module 310 may then notify the entity in which it is located of the shared data, so that the data can be consumed.
  • the usage manager 312 manages the usage information 210 for shared memory segments.
  • the usage information 210 is stored within a shared memory segment and indicates which of the chunks in that segment are currently holding shared data.
  • the usage information is a bitmap with each bit corresponding to a chunk of the shared memory segment 148 and having a value indicating whether the corresponding chunk is being utilized to store data.
  • Other embodiments may represent the usage information 210 using other techniques, such as via a linked list.
  • the usage manager 312 can update the state of the usage information 210 using atomic instructions.
  • One instruction updates the usage information 210 to indicate that a particular chunk is being used (e.g., sets a bit to 1), while another instruction updates the usage information 210 to indicate that a particular chunk is not being used (e.g., sets a bit to 0).
  • the usage manager 312 detects when data are written to a particular chunk of a shared memory segment 148 (e.g., upon notification by the data transport module 310 ) and updates the usage information to reflect that the chunk is occupied by shared data.
  • the usage manager detects 312 when data are read from a particular chunk of a shared memory segment 148 and updates the usage information to reflect that the chunk has been consumed and is available to be reused with different data. Note that this latter update is performed by the entity that is consuming the shared data.
  • the router module 132 is sharing data with the worker 136 .
  • the router module 132 writes data to a particular chunk (e.g., chunk 212 ) of the memory segment 148 a that the router module has shared with the worker 136 .
  • the usage manager 312 of the shared memory manager 228 a in the router module updates the usage information 210 a in the shared memory segment 148 a to indicate that that chunk is in use.
  • the worker 136 consumes (e.g., reads) the data in the chunk 212 of the shared memory segment 148 a .
  • the usage manager 312 of the shared memory manager 228 b in the worker 136 then updates the usage information 210 a in the shared memory segment 148 a to indicate that the chunk is no longer in use.
  • the two entities can use the usage information 210 to communicate about the current state of the shared memory segment 148 .
  • a shared memory manager 228 can reuse a chunk within a shared memory segment 148 to share new data once the old data in that segment are consumed. Due to race conditions or other circumstances, the usage information may become inaccurate. Therefore, in one embodiment, the usage manager 312 can send a control message to the entity with which the memory segment is shared requesting that the entity update its usage information. Upon receiving such a control message, the usage manager 312 resets the usage information 210 for the shared memory segment 148 to reflect the current state of the data. This control message may be sent, for example, when the usage information 210 indicates that all chunks are in use; the usage manager 312 that receives the message may then update the usage information to indicate that all or some of the chunks have been consumed.
  • This technique increases web server 128 performance and reduces latency in execution by avoiding multiple copy operations for the data.
  • Shared memory segments are created dynamically based on load balancing between server processes. Memory segments referenced by lightly loaded processes are deleted to shift resources to processes that have higher workloads. For example, a shared memory segment may be deleted responsive to the determination that the shared memory segment has not been used for a threshold period of time. The technique therefore performs processing of web applications more efficiently and reduces memory and system resource requirements.
  • Each router module 132 is able to process multiple requests simultaneously, thereby improving the distribution of workloads across multiple computing resources and reducing resource use, increasing throughput, reducing response time, and avoiding the overload of any single resource.
  • FIG. 4 is a flowchart illustrating steps performed to dynamically share data using a shared memory segment, according to one embodiment.
  • the steps of FIG. 4 may be performed by the shared memory manager 228 . Some or all of the steps may be also performed by other entities. Likewise, the shared memory manager 228 may perform the steps in different orders, and/or perform different or additional steps.
  • mapping process creates 400 a shared memory segment and obtains 410 a file descriptor referencing it.
  • the first process performs a memory map operation using the file descriptor and maps 420 the shared memory segment in its local address space.
  • the first process transmits 430 the file descriptor to the second process via a socket created prior to the communication.
  • the second process receives the file descriptor and uses it to map 440 the shared memory segment to the local address space of the second process.
  • the first process writes 450 data to be shared to one or more chunks of the shared memory segment and updates the usage information for the segment to indicate that the chunks are in use. Note that the first process may write data to one or more chunks of one or more shared memory segments.
  • the first process also sends 450 a control message to the second process via the socket that notifies the second process of the shared data.
  • the second process receives the control message and reads 460 the shared data from the chunks of the shared memory segment.
  • the second process also updates the usage information to indicate that the shared data have been consumed. Hence, the first process can reuse those chunks to share additional data in a subsequent transaction.
  • steps described above can also be performed by the second process in order to share data from the second process to the first process.
  • FIG. 5 illustrates components of an example machine 500 able to read instructions to dynamically use shared memory segments to exchange data, according to one embodiment.
  • Those of skill in the art will recognize that other embodiments of the machine 500 can have different and/or other modules than the ones described here, and that the functionalities can be distributed among the modules in a different manner.
  • FIG. 5 shows a diagrammatic representation of a machine in the example form of a computer system 500 .
  • the computer system 500 can be used to execute instructions 524 (e.g., program code modules) that cause the machine to perform any one or more of the methodologies (or processes) described herein.
  • the machine operates as a standalone device or a connected (e.g., networked) device that connects to other machines.
  • the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
  • the machine may be a server computer, a cloud server residing on a shared “virtualized” environment managed by a cloud hosting provider, a personal computer (PC), a tablet PC, a set-top box (STB), a smartphone, an internet of things (IoT) appliance, a network router, switch or bridge, or any machine capable of executing instructions 524 (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal computer
  • STB set-top box
  • smartphone an internet of things (IoT) appliance
  • network router switch or bridge
  • any machine capable of executing instructions 524 (sequential or otherwise) that specify actions to be taken by that machine.
  • machine shall also be taken to include any collection of machines that individually or jointly execute instructions 524 to perform any one or more of the methodologies discussed herein.
  • the example computer system 500 includes one or more processing units (generally processor 502 ).
  • the processor 502 is, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these.
  • the computer system 500 also includes a main memory 504 .
  • the computer system may include a storage unit 516 .
  • the processor 502 , memory 504 and the storage unit 516 communicate via a bus 508 .
  • the computer system 500 can include a static memory 506 , a screen driver 510 (e.g., to drive a plasma display panel (PDP), a liquid crystal display (LCD), or a projector).
  • the computer system 500 may also include alphanumeric input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a signal generation device 518 (e.g., a speaker), and a network interface device 520 , which also are configured to communicate via the bus 508 .
  • the storage unit 516 includes a machine-readable medium 522 on which is stored instructions 524 (e.g., program code modules) embodying any one or more of the methodologies or functions described herein.
  • the instructions 524 may also reside, completely or at least partially, within the main memory 504 or within the processor 502 (e.g., within a processor's cache memory) during execution thereof by the computer system 500 , the main memory 504 and the processor 502 also constituting machine-readable media.
  • the instructions 524 may be transmitted or received over a network 526 via the network interface device 520 .
  • machine-readable medium 522 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the instructions 524 .
  • the term “machine-readable medium” shall also be taken to include any non-transitory medium that is capable of storing instructions 524 for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein.
  • the term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

Data is dynamically shared from a first process to a second process by creating a shared memory segment, obtaining a file descriptor referencing the shared memory segment, and mapping the shared memory segment in an address space of a first process. The file descriptor is sent to a second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.

Description

BACKGROUND 1. Field of the Invention
This invention pertains in general to web server architectures and in particular to transporting data between server processes.
2. Description of the Related Art
In a traditional web server architecture, different processes accept, supervise, and process web requests and responses. The requests and responses are associated with data, such as contents of web pages, files, images, etc., that need to be transported between the different processes. The different processes have their own independent address spaces that temporarily store the data for transport and processing.
In traditional web server architectures, sockets may be used to transport data between the different address spaces. However, using sockets can require a large number of copy operations to move data between address spaces of the different processes. It is computationally inefficient for the web server to engage in the many memory copy operations, which can lead to high memory utilization and high memory overhead requirements. Moreover, copy operations require extra resources, such as locking operations for worker processes that receive data from a router process. Therefore, the performance of the web server is impacted due to the large number of copy operations for transporting data in traditional web server architectures.
SUMMARY
The above and other needs are met by methods, computer-readable storage media, and systems for dynamically sharing data from a first process to a second process.
One aspect provides a computer-implemented method for dynamically sharing data from a first process to a second process by creating a shared memory segment, obtaining a file descriptor referencing the shared memory segment, and mapping the shared memory segment in an address space of the first process. The file descriptor is sent to the second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.
Another aspect provides a non-transitory computer-readable storage medium storing executable computer program instructions for dynamically sharing data from a first process to a second process. The computer program instructions create a shared memory segment, obtain a file descriptor referencing the shared memory segment, and map the shared memory segment in an address space of the first process. The file descriptor is sent to a second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.
Still another aspect provides a system for dynamically sharing data from a first process to a second process. The system includes a computer processor and a non-transitory computer-readable storage medium storing executable computer program instructions that when executed by the computer processor perform actions including creating a shared memory segment, obtaining a file descriptor referencing the shared memory segment, and mapping the shared memory segment in an address space of a first process. The file descriptor is sent to a second process. Responsive to receiving the file descriptor, the shared memory segment is mapped in an address space of the second process. Via the shared memory segment, data from the first process is shared to the second process.
The features and advantages described in this summary and the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a high-level block diagram of a computing environment supporting use of shared memory to transport data between processes of a web server, according to one embodiment.
FIG. 2 is a high-level block diagram illustrating a more detailed view of the web server architecture, according to one embodiment.
FIG. 3 is a high-level block diagram illustrating components of a shared memory manager according to one embodiment.
FIG. 4 is a flowchart illustrating steps performed to dynamically share data using a shared memory segment, according to one embodiment.
FIG. 5 illustrates components of an example machine able to read instructions to dynamically use shared memory segments to exchange data, according to one embodiment.
The figures depict an embodiment of the invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
DETAILED DESCRIPTION
Computing Environment Supporting Dynamic Creation of a Shared Memory Server Architecture
FIG. 1 is a high-level block diagram of a computing environment 100 supporting use of shared memory to transport data between processes of a web server 128, according to one embodiment. FIG. 1 illustrates multiple client devices 104 and a web server 128 connected by a network 116. While only a few client devices 104 and one web server are shown in FIG. 1, embodiments of the computing environment 100 can have many such entities connected to the network.
FIG. 1 uses like reference numerals to identify like elements. A letter after a reference numeral, such as “140 a,” indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as “140,” refers to any or all of the elements in the figures bearing that reference numeral. For example, “140” in the text refers to reference numerals “140 a” and/or “140 b” in the figures.
A client device 104 is an electronic device used by a user to perform functions such as consuming digital content, executing software applications, browsing web sites hosted by or otherwise interacting with the web server 128 on the network 116, and downloading files. For example, the client device 104 may be a smartphone or a tablet, notebook, or desktop computer. In addition, the client device 104 may be an Internet-of-Things (IoT)-connected device such as a home appliance, or even another web server. The client device 104 may include a display device on which the user may view digital content stored on the client device 104 or downloaded from the web server 128. In addition, the client device 104 may include a user interface (UI), such as physical and/or on-screen buttons, with which the user may interact to perform functions such as consuming digital content, obtaining digital content, and transmitting digital content.
A client device 104 sends requests 108 to the web server 128 via the network 116. A request 108 seeks to access a resource maintained, controlled, or otherwise accessible by the web server 128. In one embodiment, the client device 104 sends the request 108 using the Hypertext Transfer Protocol (HTTP) or a secure variant thereof. For example, a web browser on the client device 104 may send a request 108 to the web server 128 to post or fetch a file (e.g., a web page or an image). The request 108 includes information identifying the requested resource and may also include information identifying the content to be posted, the client device 104, the server 128, and the session.
The network 116 enables communications among the client devices 104 and the web server 128. To this end, the network 116 receives requests 108 and corresponding data (e.g., contents of a file to be posted on a web page) from client devices 104 and forwards the requests 120 to the web server 128. Likewise, the network 116 receives responses 124 and corresponding data (e.g., an image to be downloaded from a web page) from the web server 128 and forwards the responses 112 to the client devices 104.
The network 116 can comprise the Internet as well as mobile telephone networks. In one embodiment, the network 116 uses standard communications technologies and/or protocols. Thus, the network 116 can include links using technologies such as Ethernet, 802.11, Long-Term Evolution (LTE), etc. The networking protocols used on the network 116 can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), HTTP, the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network 116 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some of the links can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), virtual private networks (VPNs), Internet Protocol security (IPsec), etc. In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
The web server 128 receives and processes requests 120 from the client devices 104 and sends responses 124 back to the requesting client devices 104. As mentioned above, the requests 120 received by the web server 128 are typically associated with data. For a given request 120, the web server 128 may also obtain a requested data resource and send a response 124 providing the data resource back to the requesting client device 104. The data resource is typically a file or other data, such as a web page or component thereof. Requests 120 received by the web server 128 are processed by one or more router modules 132. In one embodiment, the router module 132 is a process that analyzes the requests 120 and routes the requests 120 to one or more workers 136 for further processing. The workers 136 may be processes and/or threads executing within a process space. There may be multiple router modules 132 operating concurrently in order to support load balancing and other features. Upon processing the requests, the workers 136 send responses and data back to the router module 132.
The router module 132 and workers 136 use shared memory segments 148 to share data related to the requests and responses generated therefrom. In one embodiment, the router module 132 uses one or more shared memory segments 148 a for each worker 136 with which the router communicates. These shared memory segments 148 a are used for unidirectional communications from the router module 132 to the worker 136. A worker 136 likewise uses one or more other shared memory segments 148 b to engage in unidirectional communications with the router module 132. In addition, the router module 132 and worker 136 use a pair of unidirectional sockets 140 a, 140 b to respectively send messages about the shared memory segments 148. The sockets 140 effectively serve as control channels using which the router module 132 and worker 136 can exchange control messages about the shared memory segments 148.
Using shared memory segments 148 in this way allows the router module 132 and worker 136 to efficiently share data related to requests and responses. The sharing entity can place the data to be shared in the shared memory segment 148 and the recipient entity can read the data directly from the shared memory segment. This technique avoids the memory copy operations and additional overhead that would be incurred if the sockets were used to transport the shared data between the entities. Hence the technique is performed on web servers 128 having multiple router modules 132 and/or workers 136. In addition, this technique provides security and fault isolation by using discrete shared memory segments between each router module 132 and workers 136. While this description refers to using shared memory segments between a router module 132 and a worker 136, the techniques described herein can be used to share data between any two processes.
Shared Memory Server Architecture Supporting Data Transport
FIG. 2 is a high-level block diagram illustrating a more detailed view of the web server architecture 200, according to one embodiment. FIG. 2 illustrates the router module 132 and worker 136 of FIG. 1. In addition, FIG. 2 illustrates the pair of unidirectional sockets 140 a, 140 b and the shared memory segments 148 a, 148 b. FIG. 2 likewise illustrates that the router 132 has an associated router address space 204 and the worker 136 has an associated worker address space 208. The router module 132 and worker 136 each include a shared memory manager 228. Other embodiments of the web server 128 can have different and/or other modules than the ones described here, and the functionalities can be distributed among the modules in a different manner.
As discussed earlier, the router module 132 supervises processing of requests from the client devices 104. When an inbound request 120 with its corresponding data reaches the web server 128, it is passed to the router module 132. The router module 132 analyzes the request 120 and routes the request and its corresponding data to workers 136. The router module 132 may perform load balancing to distribute requests 120 across multiple router threads to increase throughput and reduce latency. The router module 132 may use routing policies to control the flow and assignment of requests.
The router module 132 uses the router address space 204 to store data related to its execution. The shared memory manager 228 a in the router module 132 allocates a portion of the router's address space 204 as a shared memory segment 148 a. The shared memory segment 148 a is portioned in a set of discrete chunks, with each chunk (e.g., chunk 212) holding a fixed amount of memory. In addition, a portion of the shared memory segment 148 contains usage information 210 a indicating which of the chunks are currently holding shared data. For example, the usage information 210 a may be a bitmap with each bit corresponding to a chunk of the shared memory segment 148 and having a value indicating whether the corresponding chunk is being utilized to store data.
The shared memory manager 228 a also creates a socket 140 a from the router module 132 to the worker 136. The shared memory manager 228 a passes control messages about the shared memory segment 148 a to the worker 136 via the socket 140 a. The control messages may indicate, for example, that a shared memory segment has been created or that shared data has been placed in a particular chunk of a shared memory segment. The control messages may additionally instruct the worker 136 to perform a particular function with respect to the shared memory segment 148 a, such as updating the usage information to indicate that shared data has been consumed by the worker 136.
The worker process 136 likewise has an associated worker address space 208 and shared memory manager 228 b. The shared memory manager 228 b in the worker 136 allocates a shared memory segment 148 b in the worker address space 208 and creates a socket 140 b for passing control messages about the shared memory segment to the router module 132. The worker process's shared memory segment 148 b is functionally equivalent to the router module's shared memory segment 148 a.
Each shared memory manager 228 a, 228 b also functions to receive control messages sent by the other shared memory manager. To this end, a shared memory manager 228 receives a message via a socket 140 indicating that a shared memory segment 148 has been created. Upon receipt of this type of message, the shared memory manager 228 creates a corresponding shared memory segment in the local address space (i.e., in the address space of the entity in which the shared memory manager 228 is located). The shared memory manager 228 reads data from the shared memory segment in response to additional control messages received via the socket.
Shared Memory Manager
FIG. 3 is a high-level block diagram illustrating components of a shared memory manager 228 according to one embodiment. FIG. 3 illustrates that the shared memory manager 228 includes a socket manager 304, a memory mapping module 308, a data transport module 310, and a usage manager 312. Other embodiments of the shared memory manager 228 can have different and/or other modules than the ones described here, and the functionalities can be distributed among the modules in a different manner.
The socket manager 304 performs socket-based communications for the shared memory manager 228. These communications include transmitting control messages to other shared memory managers 228 and receiving control messages from the other shared memory managers. In one embodiment, during a setup phase, the socket manager 304 interacts with the socket manager of another shared memory manager 228 to create a pair of unidirectional sockets 140 that together form a bidirectional communication channel. The socket manager uses the pair of sockets 140 to send and receive control messages. Depending upon the embodiment, the socket manager 304 may establish and use a persistent pair of sockets for communications, or may open a socket on demand when necessary to send a control message, and then close the socket after sending the message.
The memory mapping module 308 manages shared memory segments for the shared memory manager 228. This management includes creating shared memory segments in order to share data to other entities (e.g., to a router module 132 or to a worker 136) and sending control messages to instruct the other entities to create a corresponding shared memory segments. The memory mapping module 308 may create multiple shared memory segments 148 to share data with a given entity. For example, the memory mapping module 308 may initially create one shared memory segment 148, and then create additional segments as more shared memory is required. In addition, the shared memory management includes receiving control messages from other entities including notifications that shared memory segments have been created, and creating a corresponding shared memory segment based on the notification.
In one embodiment, the memory mapping module 308 creates a shared memory segment, obtains a file descriptor referencing the shared memory segment, and maps the shared memory segment in the local address space of the process in which the shared memory manager 228 is executing (i.e., in the router address space 204 or worker address space 208). In some embodiments, the memory mapping module 308 creates the shared memory segment using the Linux “memfd_create” system call. The system call returns a file descriptor referencing the shared memory segment. The memory mapping module 308 maps the shared memory segment using the UNIX “mmap( )” system call. This system call establishes a mapping between the process's local address space and the shared memory segment. The memory mapping module 308 interacts with the socket manager 304 to send a control message to the other entity with which the memory segment is to be shared. The control message includes the file descriptor for the shared memory segment.
The memory mapping module 308 may also receive a control message including a file descriptor for a shared memory segment created by a different shared memory manager 228. In this case, the memory mapping module 308 performs the mmap( ) call using the file descriptor in order to map the shared memory segment in the local address space that is shared with the corresponding memory segment in the other process's local address space.
In one embodiment, a shared memory segment is partitioned into multiple chunks. The chunks may be evenly-sized. For example, if a shared memory segment is one megabyte in size, it may be formed of eight 128 KB chunks. Alternatively, some or all of the chunks may be of different sizes. The memory mapping module 308 that creates a shared memory segment may include information about the partitioning of the memory segment in the control messages sent to the entity with which the memory segment is shared.
The data transport module 310 transports data using shared memory segments. A shared memory segment can be written and read by many sharing entities. However, in one embodiment a shared memory segment is used for only unidirectional data sharing. The entity that created the shared memory segment writes to the segment to send data to the other entity with which the memory segment is shared. Likewise, an entity reads from a shared memory segment created by another entity in order to receive data shared by the other entity.
In one embodiment, the entity sharing the data writes the data to one or more chunks of one or more shared memory segments. For example, assume the router module 132 is sharing data with the worker 136. The router module 132 writes the data to be shared to a chunk (e.g., chunk 212) of the shared memory segment 148 a that is shared with the worker 136. The router module 132 may perform this write by writing the data to the address in the router module's local address space 204 corresponding to the location of the chunk in the shared memory segment 148.
The data transport module 310 detects the write to the chunk within the shared memory segment 148 a, and notifies the entity with which the segment has been shared of the shared data. Specifically, the data transport module 310 uses the socket to send a control message to the other shared memory manager 228. The control message indicates that data has been written to the shared memory segment and identifies the chunk to which the data were written (e.g., by specifying the index of the chunk).
The data transport module 310 also detects when data has been shared by another entity. In this case, the data transport module 310 receives a control message via a socket, where the control message indicates that data has been written to a particular chunk of a shared memory segment. The data transport module 310 may then notify the entity in which it is located of the shared data, so that the data can be consumed.
The usage manager 312 manages the usage information 210 for shared memory segments. As mentioned earlier, the usage information 210 is stored within a shared memory segment and indicates which of the chunks in that segment are currently holding shared data. In one embodiment, the usage information is a bitmap with each bit corresponding to a chunk of the shared memory segment 148 and having a value indicating whether the corresponding chunk is being utilized to store data. Other embodiments may represent the usage information 210 using other techniques, such as via a linked list.
In one embodiment, the usage manager 312 can update the state of the usage information 210 using atomic instructions. One instruction updates the usage information 210 to indicate that a particular chunk is being used (e.g., sets a bit to 1), while another instruction updates the usage information 210 to indicate that a particular chunk is not being used (e.g., sets a bit to 0). The usage manager 312 detects when data are written to a particular chunk of a shared memory segment 148 (e.g., upon notification by the data transport module 310) and updates the usage information to reflect that the chunk is occupied by shared data. In addition, the usage manager detects 312 when data are read from a particular chunk of a shared memory segment 148 and updates the usage information to reflect that the chunk has been consumed and is available to be reused with different data. Note that this latter update is performed by the entity that is consuming the shared data.
For example, assume that the router module 132 is sharing data with the worker 136. In this instance, the router module 132 writes data to a particular chunk (e.g., chunk 212) of the memory segment 148 a that the router module has shared with the worker 136. The usage manager 312 of the shared memory manager 228 a in the router module updates the usage information 210 a in the shared memory segment 148 a to indicate that that chunk is in use. Subsequently, the worker 136 consumes (e.g., reads) the data in the chunk 212 of the shared memory segment 148 a. The usage manager 312 of the shared memory manager 228 b in the worker 136 then updates the usage information 210 a in the shared memory segment 148 a to indicate that the chunk is no longer in use.
Thus, through atomic operations the two entities can use the usage information 210 to communicate about the current state of the shared memory segment 148. This way, a shared memory manager 228 can reuse a chunk within a shared memory segment 148 to share new data once the old data in that segment are consumed. Due to race conditions or other circumstances, the usage information may become inaccurate. Therefore, in one embodiment, the usage manager 312 can send a control message to the entity with which the memory segment is shared requesting that the entity update its usage information. Upon receiving such a control message, the usage manager 312 resets the usage information 210 for the shared memory segment 148 to reflect the current state of the data. This control message may be sent, for example, when the usage information 210 indicates that all chunks are in use; the usage manager 312 that receives the message may then update the usage information to indicate that all or some of the chunks have been consumed.
In this manner, efficient data transport is attained using a pool of dynamically allocated shared memory segments 148 to simultaneously process different requests 120. This technique increases web server 128 performance and reduces latency in execution by avoiding multiple copy operations for the data. Shared memory segments are created dynamically based on load balancing between server processes. Memory segments referenced by lightly loaded processes are deleted to shift resources to processes that have higher workloads. For example, a shared memory segment may be deleted responsive to the determination that the shared memory segment has not been used for a threshold period of time. The technique therefore performs processing of web applications more efficiently and reduces memory and system resource requirements. Each router module 132 is able to process multiple requests simultaneously, thereby improving the distribution of workloads across multiple computing resources and reducing resource use, increasing throughput, reducing response time, and avoiding the overload of any single resource.
Process for Transporting Data Over a Shared Memory Segment
FIG. 4 is a flowchart illustrating steps performed to dynamically share data using a shared memory segment, according to one embodiment. The steps of FIG. 4 may be performed by the shared memory manager 228. Some or all of the steps may be also performed by other entities. Likewise, the shared memory manager 228 may perform the steps in different orders, and/or perform different or additional steps.
Assume for purposes of FIG. 1 that data are shared from a first process (e.g., the router module 132) to a second process (e.g., a worker). In one embodiment, the mapping process creates 400 a shared memory segment and obtains 410 a file descriptor referencing it. The first process performs a memory map operation using the file descriptor and maps 420 the shared memory segment in its local address space.
The first process transmits 430 the file descriptor to the second process via a socket created prior to the communication. The second process receives the file descriptor and uses it to map 440 the shared memory segment to the local address space of the second process. The first process writes 450 data to be shared to one or more chunks of the shared memory segment and updates the usage information for the segment to indicate that the chunks are in use. Note that the first process may write data to one or more chunks of one or more shared memory segments. The first process also sends 450 a control message to the second process via the socket that notifies the second process of the shared data.
The second process receives the control message and reads 460 the shared data from the chunks of the shared memory segment. The second process also updates the usage information to indicate that the shared data have been consumed. Hence, the first process can reuse those chunks to share additional data in a subsequent transaction.
The steps described above can also be performed by the second process in order to share data from the second process to the first process.
Example Machine Providing a Shared Memory
FIG. 5 illustrates components of an example machine 500 able to read instructions to dynamically use shared memory segments to exchange data, according to one embodiment. Those of skill in the art will recognize that other embodiments of the machine 500 can have different and/or other modules than the ones described here, and that the functionalities can be distributed among the modules in a different manner.
Specifically, FIG. 5 shows a diagrammatic representation of a machine in the example form of a computer system 500. The computer system 500 can be used to execute instructions 524 (e.g., program code modules) that cause the machine to perform any one or more of the methodologies (or processes) described herein. In alternative embodiments, the machine operates as a standalone device or a connected (e.g., networked) device that connects to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
The machine may be a server computer, a cloud server residing on a shared “virtualized” environment managed by a cloud hosting provider, a personal computer (PC), a tablet PC, a set-top box (STB), a smartphone, an internet of things (IoT) appliance, a network router, switch or bridge, or any machine capable of executing instructions 524 (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute instructions 524 to perform any one or more of the methodologies discussed herein.
The example computer system 500 includes one or more processing units (generally processor 502). The processor 502 is, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a controller, a state machine, one or more application specific integrated circuits (ASICs), one or more radio-frequency integrated circuits (RFICs), or any combination of these. The computer system 500 also includes a main memory 504. The computer system may include a storage unit 516. The processor 502, memory 504 and the storage unit 516 communicate via a bus 508.
In addition, the computer system 500 can include a static memory 506, a screen driver 510 (e.g., to drive a plasma display panel (PDP), a liquid crystal display (LCD), or a projector). The computer system 500 may also include alphanumeric input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a signal generation device 518 (e.g., a speaker), and a network interface device 520, which also are configured to communicate via the bus 508.
The storage unit 516 includes a machine-readable medium 522 on which is stored instructions 524 (e.g., program code modules) embodying any one or more of the methodologies or functions described herein. The instructions 524 may also reside, completely or at least partially, within the main memory 504 or within the processor 502 (e.g., within a processor's cache memory) during execution thereof by the computer system 500, the main memory 504 and the processor 502 also constituting machine-readable media. The instructions 524 may be transmitted or received over a network 526 via the network interface device 520.
While machine-readable medium 522 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the instructions 524. The term “machine-readable medium” shall also be taken to include any non-transitory medium that is capable of storing instructions 524 for execution by the machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The term “machine-readable medium” includes, but not be limited to, data repositories in the form of solid-state memories, optical media, and magnetic media.
The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope of the invention.

Claims (20)

What is claimed is:
1. A computer-implemented method for dynamically sharing data from a first process to a second process in a server, comprising:
creating, by the first process, a shared memory segment in server memory, wherein the shared memory segment comprises an amount of memory and a usage information portion indicative of usage of the amount of memory;
retrieving, by the first process, a file descriptor referencing the shared memory segment;
mapping, by the first process, using the file descriptor, the shared memory segment to a process address space of the first process comprising server memory allocated for the first process;
creating, by the first process, a unidirectional socket from the first process to the second process, wherein the unidirectional socket is configured such that the first process may communicate unidirectionally to the second process via the unidirectional socket;
sending, by the first process, the file descriptor to the second process using the unidirectional socket;
responsive to receiving the file descriptor, mapping, by the second process, using the file descriptor, the shared memory segment to a process address space of the second process comprising server memory allocated for the second process;
writing, by the first process, the data to the amount of memory in the shared memory segment using the mapped process address space of the first process and the usage information portion;
sending, by the first process, a control message to the second process indicating that the data is in the shared memory segment using the unidirectional socket; and
responsive to receiving the control message, reading, by the second process, the data in the shared memory segment using the mapped process address space of the second process.
2. The computer-implemented method of claim 1, wherein the shared memory segment comprises a plurality of chunks.
3. The computer-implemented method of claim 1, wherein the sharing comprises:
examining the usage information portion of the shared memory segment to identify that one or more chunks of the shared memory segment are available to share the data;
writing, by the first process, the data to the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been written.
4. The computer-implemented method of claim 1, wherein the sharing comprises:
examining the usage information portion of the shared memory segment to identify that the data has been written to one or more chunks of the shared memory segment;
reading, by the second process, the data from the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been read.
5. The computer-implemented method of claim 1, further comprising:
responsive to determining that none of a plurality of chunks of the shared memory segment are available to transport data, mapping a new shared memory segment in the process address space of the first process.
6. The computer-implemented method of claim 1, wherein the shared memory segment is one of a plurality of shared memory segments and each of the shared memory segments comprises a corresponding plurality of chunks, the method further comprising:
responsive to determining that none of the corresponding pluralities of chunks is available to transport data and that a maximum number of shared memory segments have been mapped, transmitting a control message to the second process to update the usage information portion of the plurality of shared memory segments to notify the first process when a chunk is available to transport data.
7. The computer-implemented method of claim 1, further comprising:
determining whether the shared memory segment has been used within a threshold period of time; and
deleting the shared memory segment responsive to determining that the shared memory segment has not been used for the threshold period of time.
8. A non-transitory computer-readable storage medium storing executable computer program instructions for dynamically creating a shared memory architecture for a server comprising a first process and a second process, the computer program instructions comprising instructions for:
creating, by the first process, a shared memory segment in server memory, wherein the shared memory segment comprises an amount of memory and a usage information portion indicative of usage of the amount of memory;
retrieving, by the first process, a file descriptor referencing the shared memory segment;
mapping, by the first process, using the file descriptor, the shared memory segment to a process address space of the first process comprising server memory allocated for the first process;
creating, by the first process, a unidirectional socket from the first process to the second process, wherein the unidirectional socket is configured such that the first process may communicate unidirectionally to the second process via the unidirectional socket;
sending, by the first process, the file descriptor to the second process using the unidirectional socket;
responsive to receiving the file descriptor, mapping, by the second process, using the file descriptor, the shared memory segment to a process address space of the second process comprising server memory allocated for the second process;
writing, by the first process, data to the amount of memory in the shared memory segment using the mapped process address space of the first process and the usage information portion;
sending, by the first process, a control message to the second process indicating that the data is in the shared memory segment using the unidirectional socket; and
responsive to receiving the control message, reading, by the second process, the data in the shared memory segment using the mapped process address space of the second process.
9. The non-transitory computer-readable storage medium of claim 8, wherein the shared memory segment comprises a plurality of chunks.
10. The non-transitory computer-readable storage medium of claim 8, the computer program instructions further comprising instructions for:
examining the usage information portion of the shared memory segment to identify that one or more chunks of the shared memory segment are available to share the data;
writing, by the first process, the data to the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been written.
11. The non-transitory computer-readable storage medium of claim 8, the computer program instructions further comprising instructions for:
examining the usage information portion of the shared memory segment to identify that the data has been written to one or more chunks of the shared memory segment;
reading, by the second process, the data from the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been read.
12. The non-transitory computer-readable storage medium of claim 8, the computer program instructions further comprising instructions for:
responsive to determining that none of a plurality of chunks of the shared memory segment are available to transport data, mapping a new shared memory segment in the process address space of the first process.
13. The non-transitory computer-readable storage medium of claim 8, wherein the shared memory segment is one of a plurality of shared memory segments and each of the shared memory segments comprises a corresponding plurality of chunks, the computer program instructions further comprising instructions for:
responsive to determining that none of the corresponding pluralities of chunks is available to transport data and that a maximum number of shared memory segments have been mapped, transmitting a control message to the second process to update the usage information portion of the plurality of shared memory segments to notify the first process when a chunk is available to transport data.
14. The non-transitory computer-readable storage medium of claim 8, the computer program instructions further comprising instructions for:
determining whether the shared memory segment has been used within a threshold period of time; and
deleting the shared memory segment responsive to determining that the shared memory segment has not been used for the threshold period of time.
15. A computer system comprising:
a computer processor; and
a non-transitory computer-readable storage medium storing executable computer program instructions that when executed by the computer processor perform actions for dynamically sharing data from a first process to a second process in a server, the actions comprising:
creating, by the first process, a shared memory segment in server memory, wherein the shared memory segment comprises an amount of memory and a usage information portion indicative of usage of the amount of memory;
retrieving, by the first process, a file descriptor referencing the shared memory segment;
mapping, by the first process, using the file descriptor, the shared memory segment to a process address space of the first process comprising server memory allocated for the first process;
creating, by the first process, a unidirectional socket from the first process to the second process, wherein the unidirectional socket is configured such that the first process may communicate unidirectionally to the second process via the unidirectional socket;
sending, by the first process, the file descriptor to the second process using the unidirectional socket;
responsive to receiving the file descriptor, mapping, by the second process, using the file descriptor, the shared memory segment to a process address space of the second process comprising server memory allocated for the second process;
writing, by the first process, the data to the amount of memory in the shared memory segment using the mapped process address space of the first process and the usage information portion;
sending, by the first process, a control message to the second process indicating that the data is in the shared memory segment using the unidirectional socket; and
responsive to receiving the control message, reading, by the second process, the data in the shared memory segment using the mapped process address space of the second process.
16. The computer system of claim 15, the actions further comprising:
examining the usage information portion of the shared memory segment to identify that one or more chunks of the shared memory segment are available to share the data;
writing, by the first process, the data to the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been written.
17. The computer system of claim 15, the actions further comprising:
examining the usage information portion of the shared memory segment to identify that the data has been written to one or more chunks of the shared memory segment;
reading, by the second process, the data from the one or more chunks; and
updating the usage information portion to indicate that the one or more chunks have been read.
18. The computer system of claim 15, the actions further comprising:
responsive to determining that none of a plurality of chunks of the shared memory segment are available to transport data, mapping a new shared memory segment in the process address space of the first process.
19. The computer system of claim 15, wherein the shared memory segment is one of a plurality of shared memory segments and each of the shared memory segments comprises a corresponding plurality of chunks, the actions further comprising:
responsive to determining that none of the corresponding pluralities of chunks is available to transport data and that a maximum number of shared memory segments have been mapped, transmitting a control message to the second process to update the usage information portion of the plurality of shared memory segments to notify the first process when a chunk is available to transport data.
20. The computer system of claim 15, the actions further comprising:
determining whether the shared memory segment has been used within a threshold period of time; and
deleting the shared memory segment responsive to determining that the shared memory segment has not been used for the threshold period of time.
US15/695,745 2017-09-05 2017-09-05 Using shared memory to transport data between server processes Active 2037-09-30 US10467151B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/695,745 US10467151B2 (en) 2017-09-05 2017-09-05 Using shared memory to transport data between server processes
US16/601,180 US11249923B1 (en) 2017-09-05 2019-10-14 Using shared memory to transport data between server processes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/695,745 US10467151B2 (en) 2017-09-05 2017-09-05 Using shared memory to transport data between server processes

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/601,180 Continuation US11249923B1 (en) 2017-09-05 2019-10-14 Using shared memory to transport data between server processes

Publications (2)

Publication Number Publication Date
US20190073316A1 US20190073316A1 (en) 2019-03-07
US10467151B2 true US10467151B2 (en) 2019-11-05

Family

ID=65518665

Family Applications (2)

Application Number Title Priority Date Filing Date
US15/695,745 Active 2037-09-30 US10467151B2 (en) 2017-09-05 2017-09-05 Using shared memory to transport data between server processes
US16/601,180 Active 2038-07-04 US11249923B1 (en) 2017-09-05 2019-10-14 Using shared memory to transport data between server processes

Family Applications After (1)

Application Number Title Priority Date Filing Date
US16/601,180 Active 2038-07-04 US11249923B1 (en) 2017-09-05 2019-10-14 Using shared memory to transport data between server processes

Country Status (1)

Country Link
US (2) US10467151B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112269655A (en) * 2020-10-15 2021-01-26 北京百度网讯科技有限公司 Memory mapping file cleaning method and device, electronic equipment and storage medium

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11042424B1 (en) * 2018-04-24 2021-06-22 F5 Networks, Inc. Pipelined request processing using shared memory
US10972449B1 (en) * 2018-06-28 2021-04-06 Amazon Technologies, Inc. Communication with components of secure environment
CN111176855B (en) * 2018-11-09 2023-10-27 微软技术许可有限责任公司 Establishing queues between threads in user space
CN115119048B (en) * 2019-08-10 2024-02-23 荣耀终端有限公司 Video stream processing method and electronic equipment
CN112559196B (en) * 2019-09-10 2024-03-26 航天科工惯性技术有限公司 Transmission method for sharing communication data between processes
US11119931B1 (en) * 2019-09-18 2021-09-14 Facebook Technologies, Llc Data pipeline for microkernel operating system
CN111797497B (en) * 2020-05-21 2024-05-17 中国电力科学研究院有限公司 Communication method and system for electromagnetic transient parallel simulation
CN111897666B (en) * 2020-08-05 2024-02-06 北京图森未来科技有限公司 Method, device and system for communication between multiple processes
CN113485849A (en) * 2020-09-09 2021-10-08 青岛海信电子产业控股股份有限公司 Image identification method and management equipment
CN112906075A (en) * 2021-03-15 2021-06-04 北京字节跳动网络技术有限公司 Memory sharing method and device
CN113630442B (en) * 2021-07-14 2023-09-12 远景智能国际私人投资有限公司 Data transmission method, device and system
CN114528124B (en) * 2022-02-17 2024-09-03 福建天晴在线互动科技有限公司 Protocol-based process big data memory sharing method and system
CN114615273B (en) * 2022-03-02 2023-08-01 北京百度网讯科技有限公司 Data transmission method, device and equipment based on load balancing system
CN114827151B (en) * 2022-05-20 2024-07-12 合肥边缘智芯科技有限公司 Heterogeneous server cluster, and data forwarding method, device and equipment
CN117372236B (en) * 2022-07-06 2024-09-06 格兰菲智能科技股份有限公司 Shared memory access method, device and computer equipment
CN117009114B (en) * 2023-10-07 2024-05-28 联通(广东)产业互联网有限公司 Data sharing method and device, electronic equipment and storage medium

Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4387441A (en) * 1981-04-16 1983-06-07 Ncr Corporation Data processing system wherein at least one subsystem has a local memory and a mailbox memory within the local memory for storing header information
US4769771A (en) * 1984-01-20 1988-09-06 U.S. Philips Corporation Multiprocessor system comprising a plurality of data processors which are interconnected by a communication network
US5376752A (en) * 1993-02-10 1994-12-27 Korg, Inc. Open architecture music synthesizer with dynamic voice allocation
US5437031A (en) * 1990-10-10 1995-07-25 Fuji Xerox Co., Ltd. Interprocess communications control system
US5903627A (en) * 1996-11-13 1999-05-11 Siemens Information And Communication Networks, Inc. System and method for improving delivery of messages to a messaging system
US5956754A (en) * 1997-03-03 1999-09-21 Data General Corporation Dynamic shared user-mode mapping of shared memory
US6085296A (en) * 1997-11-12 2000-07-04 Digital Equipment Corporation Sharing memory pages and page tables among computer processes
US6125401A (en) * 1995-04-03 2000-09-26 International Business Machines Corporation Server detection of client process termination
US6161169A (en) * 1997-08-22 2000-12-12 Ncr Corporation Method and apparatus for asynchronously reading and writing data streams into a storage device using shared memory buffers and semaphores to synchronize interprocess communications
US6163801A (en) * 1998-10-30 2000-12-19 Advanced Micro Devices, Inc. Dynamic communication between computer processes
US20020144006A1 (en) * 2000-10-04 2002-10-03 Cranston Wayne M. High performance interprocess communication
US20030061395A1 (en) * 1998-06-29 2003-03-27 Brent A. Kingsbury Message passing using shared memory of a computer
US20030097489A1 (en) * 2001-11-21 2003-05-22 Nagendra Nagarajayya Fast socket technology implementation using semaphores and memory maps
US6735770B1 (en) * 1998-04-27 2004-05-11 Sun Microsystems, Inc. Method and apparatus for high performance access to data in a message store
US6785892B1 (en) * 2000-06-23 2004-08-31 Unisys Communications between partitioned host processors and management processor
US20050044551A1 (en) * 2003-08-19 2005-02-24 Sodhi Ajit S. System and method for shared memory based IPC queue template having event based notification
US20050091439A1 (en) * 2003-10-24 2005-04-28 Saleem Mohideen Methods and apparatus for a dual address space operating system
US20060053267A1 (en) * 2004-08-18 2006-03-09 International Business Machines Corporation Scaling address space utilization in a multi-threaded, multi-processor computer
US20080072236A1 (en) * 2005-03-10 2008-03-20 Pope Steven L Data processing system
US7549151B2 (en) * 2005-02-14 2009-06-16 Qnx Software Systems Fast and memory protected asynchronous message scheme in a multi-process and multi-thread environment
US7552440B1 (en) * 1999-09-28 2009-06-23 Rockwell Automation Technologies, Inc. Process communication multiplexer
US7653675B2 (en) * 2005-08-08 2010-01-26 Freescale Semiconductor, Inc. Convolution operation in a multi-mode wireless processing system
US20100030975A1 (en) * 2008-07-29 2010-02-04 Transitive Limited Apparatus and method for handling page protection faults in a computing system
US20110314238A1 (en) * 2010-06-16 2011-12-22 International Business Machines Corporation Common memory programming
US8281060B2 (en) * 2006-09-27 2012-10-02 Intel Corporation Virtual heterogeneous channel for message passing
US20130117761A1 (en) * 2011-11-07 2013-05-09 International Business Machines Corporation Intranode Data Communications In A Parallel Computer
US20130219057A1 (en) * 2013-03-15 2013-08-22 Concurix Corporation Relationships Derived from Trace Data
US20140289725A1 (en) * 2013-03-19 2014-09-25 Hewlett-Packard Development Company, L.P. Threads in operating systems without kernel thread support
US20150186192A1 (en) * 2013-12-27 2015-07-02 Kaspersky Lab Zao System and method for selecting a synchronous or asynchronous interprocess communication mechanism
US20160043897A1 (en) * 2013-03-21 2016-02-11 Tencent Technology (Shenzhen) Company Limited Method and configuration center server for configuring server cluster

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6886031B2 (en) * 2001-03-29 2005-04-26 Sun Microsystems, Inc. Efficient connection and memory management for message passing on a single SMP or a cluster of SMPs
US10778623B1 (en) * 2018-10-31 2020-09-15 Snap Inc. Messaging and gaming applications communication platform
US10805246B1 (en) * 2019-06-12 2020-10-13 International Business Machines Corporation Direct communication between a secure application and a local application running on the same device

Patent Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4387441A (en) * 1981-04-16 1983-06-07 Ncr Corporation Data processing system wherein at least one subsystem has a local memory and a mailbox memory within the local memory for storing header information
US4769771A (en) * 1984-01-20 1988-09-06 U.S. Philips Corporation Multiprocessor system comprising a plurality of data processors which are interconnected by a communication network
US5437031A (en) * 1990-10-10 1995-07-25 Fuji Xerox Co., Ltd. Interprocess communications control system
US5376752A (en) * 1993-02-10 1994-12-27 Korg, Inc. Open architecture music synthesizer with dynamic voice allocation
US6125401A (en) * 1995-04-03 2000-09-26 International Business Machines Corporation Server detection of client process termination
US5903627A (en) * 1996-11-13 1999-05-11 Siemens Information And Communication Networks, Inc. System and method for improving delivery of messages to a messaging system
US5956754A (en) * 1997-03-03 1999-09-21 Data General Corporation Dynamic shared user-mode mapping of shared memory
US6161169A (en) * 1997-08-22 2000-12-12 Ncr Corporation Method and apparatus for asynchronously reading and writing data streams into a storage device using shared memory buffers and semaphores to synchronize interprocess communications
US6085296A (en) * 1997-11-12 2000-07-04 Digital Equipment Corporation Sharing memory pages and page tables among computer processes
US6735770B1 (en) * 1998-04-27 2004-05-11 Sun Microsystems, Inc. Method and apparatus for high performance access to data in a message store
US20030061395A1 (en) * 1998-06-29 2003-03-27 Brent A. Kingsbury Message passing using shared memory of a computer
US6163801A (en) * 1998-10-30 2000-12-19 Advanced Micro Devices, Inc. Dynamic communication between computer processes
US7552440B1 (en) * 1999-09-28 2009-06-23 Rockwell Automation Technologies, Inc. Process communication multiplexer
US6785892B1 (en) * 2000-06-23 2004-08-31 Unisys Communications between partitioned host processors and management processor
US20020144006A1 (en) * 2000-10-04 2002-10-03 Cranston Wayne M. High performance interprocess communication
US20030097489A1 (en) * 2001-11-21 2003-05-22 Nagendra Nagarajayya Fast socket technology implementation using semaphores and memory maps
US20050044551A1 (en) * 2003-08-19 2005-02-24 Sodhi Ajit S. System and method for shared memory based IPC queue template having event based notification
US20050091439A1 (en) * 2003-10-24 2005-04-28 Saleem Mohideen Methods and apparatus for a dual address space operating system
US20060053267A1 (en) * 2004-08-18 2006-03-09 International Business Machines Corporation Scaling address space utilization in a multi-threaded, multi-processor computer
US7549151B2 (en) * 2005-02-14 2009-06-16 Qnx Software Systems Fast and memory protected asynchronous message scheme in a multi-process and multi-thread environment
US20080072236A1 (en) * 2005-03-10 2008-03-20 Pope Steven L Data processing system
US7653675B2 (en) * 2005-08-08 2010-01-26 Freescale Semiconductor, Inc. Convolution operation in a multi-mode wireless processing system
US8281060B2 (en) * 2006-09-27 2012-10-02 Intel Corporation Virtual heterogeneous channel for message passing
US20100030975A1 (en) * 2008-07-29 2010-02-04 Transitive Limited Apparatus and method for handling page protection faults in a computing system
US20110314238A1 (en) * 2010-06-16 2011-12-22 International Business Machines Corporation Common memory programming
US20130117761A1 (en) * 2011-11-07 2013-05-09 International Business Machines Corporation Intranode Data Communications In A Parallel Computer
US20130219057A1 (en) * 2013-03-15 2013-08-22 Concurix Corporation Relationships Derived from Trace Data
US20140289725A1 (en) * 2013-03-19 2014-09-25 Hewlett-Packard Development Company, L.P. Threads in operating systems without kernel thread support
US20160043897A1 (en) * 2013-03-21 2016-02-11 Tencent Technology (Shenzhen) Company Limited Method and configuration center server for configuring server cluster
US20150186192A1 (en) * 2013-12-27 2015-07-02 Kaspersky Lab Zao System and method for selecting a synchronous or asynchronous interprocess communication mechanism

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Jazayeri, M., Java, In Encyclopedia of Software Engineering, 2002, J. J. Marciniak (Ed.), p. 9. (Year: 2002). *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112269655A (en) * 2020-10-15 2021-01-26 北京百度网讯科技有限公司 Memory mapping file cleaning method and device, electronic equipment and storage medium

Also Published As

Publication number Publication date
US20190073316A1 (en) 2019-03-07
US11249923B1 (en) 2022-02-15

Similar Documents

Publication Publication Date Title
US11249923B1 (en) Using shared memory to transport data between server processes
US11941425B2 (en) Systems and methods for tuning containers in a high availability environment
US10333975B2 (en) Enhanced computing system security using a secure browser
US11516312B2 (en) Kubernetes as a distributed operating system for multitenancy/multiuser
US10985981B2 (en) Multi-threaded server architecture supporting dynamic reconfiguration
US9535871B2 (en) Dynamic routing through virtual appliances
US9363172B2 (en) Managing a configurable routing scheme for virtual appliances
US9454392B2 (en) Routing data packets between virtual machines using shared memory without copying the data packet
US9218193B2 (en) Distributed virtual machine image management for cloud computing
US8145774B2 (en) Progressively accessing data blocks related to pages
US20170171245A1 (en) Dynamic detection and reconfiguration of a multi-tenant service
US20110010629A1 (en) Selectively distributing updates of changing images to client devices
CN109729040B (en) Method, apparatus and computer readable medium for selection of a protocol
US10805652B1 (en) Stateful server-less multi-tenant computing at the edge
US10506072B2 (en) Passing listener sockets between web server processes
JP2015507787A (en) Autonomous network streaming
CN113315706B (en) Private cloud flow control method, device and system
US11436524B2 (en) Hosting machine learning models
US11562288B2 (en) Pre-warming scheme to load machine learning models
EP3384384A1 (en) Methods and devices for acquiring data using virtual machine and host machine
US11042424B1 (en) Pipelined request processing using shared memory
KR20150102388A (en) Network computing system based cloud
Panarello et al. A big video data transcoding service for social media over federated clouds
US8442939B2 (en) File sharing method, computer system, and job scheduler
WO2016095377A1 (en) Image display method and device for thin client and electronic equipment

Legal Events

Date Code Title Description
AS Assignment

Owner name: NGINX, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SYSOEV, IGOR;BARTENEV, VALENTIN;SHADRIN, NIKOLAY;AND OTHERS;REEL/FRAME:043492/0602

Effective date: 20170901

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

AS Assignment

Owner name: NGINX, VIRGIN ISLANDS, BRITISH

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE'S REGISTERED OFFICE PREVIOUSLY RECORDED ON REEL 043492 FRAME 0602. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:SYSOEV, IGOR;BARTENEV, VALENTIN;SHADRIN, NIKOLAY;AND OTHERS;SIGNING DATES FROM 20190713 TO 20190717;REEL/FRAME:049831/0432

AS Assignment

Owner name: NGINX, INC., VIRGIN ISLANDS, BRITISH

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 049831 FRAME: 0432. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:SYSOEV, IGOR;BARTENEV, VALENTIN;SHADRIN, NIKOLAY;AND OTHERS;SIGNING DATES FROM 20190713 TO 20190717;REEL/FRAME:049967/0941

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: F5 NETWORKS, INC., WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NGINX, INC.;REEL/FRAME:050753/0158

Effective date: 20191009

FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4