Patent Application
20080025302
Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
There will be described a method and apparatus that allows a networking service client over a computer network, such as the Internet, to continue to send requests and not receive any “No Listener” errors, even when the networking application on the server system is temporarily unavailable due to an application crash, or is otherwise halted.
Such an application crash could be caused, for instance, by a bug within the application, by the application electing to exit and restart due to the detection of an irrecoverable error during its course of execution, or the application could be halted by a system administrator restarting the application with new/additional parameters/configuration.
The technique will be described in relation to the TCP/IP protocols, but the technique described does not change the functionality of the TCP/IP. However, it will be appreciated by those skilled in the art that technique may be applicable to other network protocols, such as any OSI (Open System Interconnect) Layer 4 Connection Oriented Transport Service protocol, with appropriate modifications.
The technique ensures that the address and the port will remain active and that the TCP/IP stack will continue to accept incoming requests for the address and the port, and pass on these requests to the networking application when it restarts.
The result of the method is that the remote client will continue to wait until the networking application that provides the service is restarted at which time the client's requests are serviced.
The method can be provided as a feature in the networking stack. However, the TCP/IP specifications require that if there is no application providing a service on a port, the networking stack should send a “No Listener” message. Therefore, it is recommended that the method of the invention is implemented as an optional feature of the networking stack which can be turned on or off by the system administrator. This is recommended on the basis that the system administrator may use it if they find it useful or disable it if they would rather have a system that conforms to the standards. Furthermore the ability to turn the feature off allows for special situations such as, if the application that uses this feature crashes repeatedly upon restart, the system administrator can choose to have the remote clients receive a “No Listener” message instead of waiting endlessly while the problem (application not starting up correctly) is diagnosed and rectified.
Referring to
In step 1, networking application 10 creates a listening endpoint using the following sequence:
In step 2, the client initiates a connection to the networking application by sending a TCP SYN packet to the port on which the networking application is listening.
In step 3, the TCP/IP stack on the server verifies that a stream is listening for requests on this port and responds to the client with a TCP SYN-ACK packet.
In step 4, the client sends a TCP ACK packet, thus establishing the connection.
In step 5, the server sends a TPI T_CONN_IND message upstream to the socket layer.
In step 6, the socket layer wakes up the networking application, informing that there is an incoming request.
In step 7, the networking application wakes up, reads the incoming request and responds appropriately, thus providing the service to the client over the network.
When the client is finished with utilising the service the TCP/IP connection is shutdown, in step 8, by mutual consent of the server and the client.
If for some reason (such as a bug in the networking application), the application is killed by the operating system or is otherwise halted, the socket layer of this general type is normally arranged to dismantle all the listening streams set up by the networking application by issuing appropriate commands to the TCP/IP stack. Therefore under normal circumstances when the networking application dies due to some reason, the service that it was providing becomes unavailable. When it is restarted, it goes through the same process as before to register a service and cause the TCP/IP stack to set up a listening stream.
In these circumstances, while the service is unavailable, clients requesting the service will receive a “No Listener” error. Upon receiving such an error the client may do one of the following:
The technique to be described below ensures that a client does not receive a “No Listener” error when it tries to connect to the networking application. This is achieved by selectively maintaining, rather than dismantling, the listening stream when the networking application is killed.
A method of operation will be described with reference to
When the networking application 13 creates a listening endpoint (such as in step 1), it also may specify to the socket layer that the newly created listening stream has to be made persistent 14. The means of doing this is specific to the operating system in which the invention is operating. In a UNIX computer system this may be done by using a suitable ioctl( ) call which is made by an application and can alter properties of a socket. The socket layer 15 then marks or flags the socket structure 16 associated with the stream as a persistent stream 17. When the operating system kills 18 the application 13, it tells the socket layer 15 to close 19 the socket associated with the listening stream in the normal way. However, the socket layer 15 looks at the associated socket structure 16 and sees that this is a persistent connection 17. Instead of dismantling the stream (as is the default case), it simply moves the socket structure into a list of persistent connections 20. Since the socket layer never informs the TCP/IP stack to dismantle the stream, the TCP/IP stack continues to accept incoming connections, as if nothing had happened, and queues the connections for servicing.
Any data for the new connection transmitted with the incoming connections are queued for servicing as well.
Referring to
It will be appreciated that a separate module between the networking application and the socket layer could perform the above-described enhanced functionality of the socket layer. However, as this module will have to replicate significant functionality of the operating system, it is expected to be more likely that this functionality be encapsulated within the socket layer.
When the application exits normally, it will want to close the socket and dismantle the stream. The application accomplishes this by resetting the “persistent” flag 17 on the socket and closing the socket.
The technique is most effective when the administrator has made provisions to restart the application automatically when it crashes. This is a simple and trivial task on most operating systems, particularly UNIX.
In this way, the potential for unavailability of a port address between a network application crash and restart can be reduced. In consequence:
There has been described a method of managing a network port, comprising the steps of: a networking application requesting to listen on the network port; a networking layer opening the port for listening; and the networking layer maintaining the port open for listening if the execution of the networking application halts.
The networking layer may receive a indication from the networking application as to whether the network port is to be persistent and mark the network port as persistent or otherwise in accordance with the indication.
When the execution of the networking application halts, the networking layer may determine whether the network port is marked as persistent and, if the network port is marked as persistent, not dismantle the network port, but rather place the network port in a storage structure for persistent connections.
If execution of the networking application resumes and the networking application requests to listen on a network port, the networking layer may search the storage structure for the network port and if the network port is found in the storage structure, the network port may be retrieved from the storage structure and associated with the socket corresponding to the request.
There has also been described apparatus for managing a network port, comprising:
a collection of open ports; a collection of flags, each flag corresponding to an open port;
wherein the status of the flag comprises persistent or non-persistent; a storage structure for storing a list of open ports with a corresponding flag with status of persistent; and
a logic unit arranged for: setting the flags on the instructions of a networking application;
opening a port on the instruction of a networking application; placing an open port in the list in the storage structure if the networking application is halted and the corresponding flag is persistent; closing an open port if the networking application is halted and the corresponding flag is non-persistent; assigning a networking application a port from the storage structure if the networking application requests a port that is already stored in the list in the storage structure.
The logic unit may be a socket layer and may be part of a TCP/IP stack.
It will be understood that the techniques described may be implemented in the form of a computer program product comprising program code elements for carrying out the above described method. The computer program product may take the form of a socket layer and/or a TCP/IP stack.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1339/CHE/2006 | Jul 2006 | IN | national |
