Requesting high availability for network connections through control messages
US-9253025-B1 · Feb 2, 2016 · US
US10348840B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10348840-B2 |
| Application number | US-201715406903-A |
| Country | US |
| Kind code | B2 |
| Filing date | Jan 16, 2017 |
| Priority date | Jan 16, 2017 |
| Publication date | Jul 9, 2019 |
| Grant date | Jul 9, 2019 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
In a network capable of handling a number of concurrent network connections between network nodes, referred to as client and server, the client and server connection managers are customized by adding respective status handler components which add server status information requests, from client to server, and responsive status information, from server to client into message headers of messages being sent between the server and client. The supported server status information types for any given connection are defined when a connection is established through dialogue between the client and server, and then persist for the lifetime of the connection. The customizations of the server and client connection managers are modest and the increase in network traffic over the connection is proportionally very small. Moreover, status information requests can be processed and responded to quickly by attaching to messages that are being sent between the nodes.
Opening claim text (preview).
What is claimed is: 1. A computer-implemented method performed on a server with a server connection manager in order to control workflow relating to server status information requests received from clients, the method comprising: establishing, according to a network protocol, respective concurrent network connections between the server and at least one client; managing each established network connection by sending and receiving messages from server to client and client to server respectively, wherein each message comprises a set of message headers and a message body; running a server status handler component in the server connection manager to detect and handle status information requests in message headers of incoming messages arriving from clients over the concurrent network connections, the status information requests being represented by one or more status indicators desired by the clients of status indicator types specified as part of the establishing of the concurrent network connections; for each status information request, gathering at least some of the status information requested by the client; adding the status information which has been gathered to a message header of an outgoing server-to-client message as the one or more status indicators; and sending the message containing the status information to the requesting client. 2. The method of claim 1 , wherein the server-to-client message to which the requested status information is added is a next outgoing server-to-client message to be sent to the requesting client. 3. The method of claim 1 , wherein the server-to-client message to which the requested status information is added is a message that has not been prepared specifically to respond to the message bearing the status information request which is being responded to. 4. The method of claim 1 , wherein, as part of establishing a network connection to a client, a limited set of types of status information which the server will support during persistence of the connection are defined, and wherein, for the lifetime of the connection, the server restricts itself to collecting only those types of status information for that client. 5. The method of claim 4 , wherein the supported types of status information are defined by respective server status indicators, which pursuant to service client status information requests, are selectively added to the message headers of outgoing server-to-client messages, the status indicators comprising the respective server status indicators. 6. The method of claim 5 , wherein the server status indicators are defined by the server status handler component. 7. The method of claim 1 , wherein the message containing the requested status information that is sent to the client is not the message which, according to the network protocol governing the network connection, is a response to the message which contained the status information request. 8. The method of claim 1 , further comprising running a server status handler component in a client connection manager of a client of the at least one client to: add status information requests into message headers of messages that the client sends to the server in order to request status information from the server; and monitor the headers of incoming messages received from the client to detect status information that responds to a previous status information request sent by the client. 9. The method of claim 8 , wherein the client-to-server message to which the status information request is added is a next client-to-server message to be sent to the server, which message has been prepared for reasons unrelated to making a status information request. 10. The method of claim 8 , wherein the status information request is included by adding a new flag to an existing message header of the message. 11. The method of claim 8 , wherein the status information request is included by adding a new message header to the message. 12. The method of claim 8 , wherein headers of incoming messages are monitored for a response to outstanding requests for status information by seeking server status indicators specific to a limited set of types of status information which the server will support, the status indicators comprising the sever status indicators. 13. The method of claim 8 , wherein the monitoring of headers of incoming messages for a response to outstanding requests for status information is not based on recognizing incoming messages which, according to the network protocol governing the network connection, are responses to outgoing messages that requested status information. 14. A system comprising: a memory; and a processor communicatively coupled to the memory, wherein the system performs a method in association with a server with a server connection manager in order to control workflow relating to server status information requests received from clients, the method comprising: establishing, according to a network protocol, respective concurrent network connections between the server and at least one client; managing each established network connection by sending and receiving messages from server to client and client to server respectively, wherein each message comprises a set of message headers and a message body; running a server status handler component in the server connection manager to detect and handle status information requests in message headers of incoming messages arriving from clients over the concurrent network connections, the status information requests being represented by one or more status indicators desired by the clients of status indicator types specified as part of the establishing of the concurrent network connections; for each status information request, gathering at least some of the status information requested by the client; adding the status information which has been gathered to a message header of an outgoing server-to-client message as the one or more status indicators; and sending the message containing the status information to the requesting client. 15. The system of claim 14 , wherein the server-to-client message to which the requested status information is added is a next outgoing server-to-client message to be sent to the requesting client. 16. The system of claim 14 , wherein the server-to-client message to which the requested status information is added is a message that has not been prepared specifically to respond to the message bearing the status information request which is being responded to. 17. The system of claim 14 , wherein, as part of establishing a network connection to a client, a limited set of types of status information which the server will support during persistence of the connection are defined, and wherein, for the lifetime of the connection, the server restricts itself to collecting only those types of status information for that client. 18. The system of claim 14 , wherein the supported types of status information are defined by respective server status indicators, which pursuant to service client status information requests, are selectively added to the message headers of outgoing server-to-client messages, the status indicators comprising the respective server status indicators. 19. The system of claim 14 , further comprising running a server status handler component in a client connection manager of a client of the at least one client to: add status information requests into message headers of messages that the client sends to the server in order to request status information from the serve
in which an application is distributed across nodes in the network (software deployment G06F8/60; multiprogramming arrangements G06F9/46) · CPC title
Electricity · mapped topic
Electricity · mapped topic
Discovery or management thereof, e.g. service location protocol [SLP] or web services · CPC title
Protocols · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.