CometServe Client/Server Issues
Last Updated October 30, 1998


Timeout and Retry Operations

A method of recovery must be implemented by the client for the following three cases:

In the Client/Server model, each transaction is initiated by the client (Comet 98) followed by a response from the host (CometServe).  While the protocols chosen for use with CometServe offer the best performance, they lack a guarantee of delivery, which means the client must recover, through the use of timeouts, from a lost packet.

After the client sends a Request, a response must be received within 100ms to safeguard against a lost packet. The lost Request and lost Reply simply result in a repeat Request from the client. The server must therefore ensure that every Request Packet is followed by a response within the 100ms limit. There are two responses sent from the host:

If the Progress Packet is lost, then the Reply Packet is repeated.

Once Comet 98 receives the Progress Packet, it enters an In Progress mode, whereby Progress Packets must periodically be sent by CometServe to safeguard againt the lost Reply Packet.  The Progress Packet interval is 5000ms.  However, since we are using connection-less protocols, which do not guarentee delivery, we then establish the rule that five times the number of packets must be sent to every one packet expected.  This allows that up to four packets may be lost in a row, before taking a fatal exception.  Applying the 5:1 rule therefore mandates that CometServe send a Progress Packet every 1000ms.

The pseudo code below describes the algorithm proposed to address these issues in both the client and the server.

Comet 98 Client

The above mentioned recovery methods can all be encompassed in the SendToNLM() routine.


InProgress = FALSE;                   // no progress packet received
AskUser = TRUE;                       // show user abort dialog
UserSaysAbort = FALSE;                // set by AskUserDialog()

SendAgain:

WaitAgain:

WaitForResponse()
{

}

CometServe Server

Two threads manage the progress of a client request to facilitate lost packet recovery by the client. One thread processes the Request Packet, while another sends a Progress Packet to keep the client waiting for the response.

ProcessRequestThread

WaitNextRequest:

InProgressThread()
{

}


Lost Connection Detection

A method of detection must be implemented by the server to detect lost client connections so that files owned by the client (Comet) may be closed, and security licenses may be freed.  Past methods using Server Bindery connection information has proved ineffective with MS Window Clients, since they seemingly log in and out of the server unpredictably.  This sometimes results in a client logout while Comet is still running. The CometServe /A option can be used to correct this problem by disabling the method altogether, thus resulting in orphaned licenses and open files.

It is therefore proposed that the server rely on periodic notification from the client.  This is the purpose of the Keep Alive Packet 0x1C.

At regular intervals, the client will send a Keep Alive Packet to the server. The server will record the time of day the last Keep Alive Packet was received.  After some period of inactivity, the server will then conclude that the client system is no longer active/connected.  Since connectionless protocols are used, the client interval must be many times shorter than the required server refresh interval. Further, no response is expected by the server from a Keep Alive Packet.

Until the interval times are more closely determined, we will specifiy the client Keep Alive transmission interval as 1 minute, and the server timeout interval at 5 minutes.

The CometServe registration port (low bandwidth) will be used for Keep Alive Packet notification.  No data is yet defined for the Keep Alive Packet, so it will just contain the packet header.

The pseudo code below describes the algorithm proposed to address these issues in both the client and the server.

Comet 98 Client

The above mentioned concept will be handled from Win16 C code through a multi-media timer, which shold prove to be highly accurate and reliable.  Since no delay is incurred waiting for a repsonse from the server, there should be minimal performance loss by the client system.

KeepAliveTimer(every 1 minute)
{

}

CometServe Server

Two threads manage the detection of a lost client connection.  One, a background thread, periodically examines the connection table for any connections exceeding the 5 minute Keep Alive limit, and processes the lost connection as detected. The other thread, already in place, is the foreground thread running in StartComm() which processes the requests on the Registration Socket.  As mentioned above, the client can pass the CometServe connection table handle within the body of the packet to facilitate recording the time of the last keep alive packet. 

StartComm

switch(Reqpacket.Req[0])
{

}

The interval of the KeepAliveThread should be half the client timeout limit. Thus, in the case of a 5 minute limit, the thread should check the table every 2.5 mintues.

KeepAliveThread()
{

}


CometServe Sleep Feature

This feature instructs CometServe to close all open files to allow server backup applications to access data files unhindered by shared access rights. The Sleep and Wakeup times can be scheduled via CometServe command line parameters, or Sleep Mode can be manually entered and exited through keyboard commands.

Upon entering Sleep Mode, CometServe rejects new file requests (except Logout) by responding with a Sleep Packet. Once all pending file requests have been serviced, CometServe closes all files it has open. Login requests (that may be followed by DIRADDs) are likewise rejected with Sleep Packets during the time CometServe is in Sleep Mode.

All file I/O (Work Socket) and Login (Reg Socket) requests are rejected during this time. Other operations, such as Keep Alive, continue to function as designed.

When the client submits a file request while CometServe is in Sleep Mode, CometServe responds with a Sleep Packet and ignores the request. This, in turn, causes the client to post a user message (Sleep Option) indicating that the server is in Sleep Mode. The user is then given the choice to wait or cancel the operation. The Sleep Packet contains Wakeup time information, which is passed along to the user in the Sleep Option message. If the user chooses to wait, then the Sleep Option message changes allowing the user to abort waiting. If the user chooses to cancel the operation, or abort waiting for Sleep Mode to end, the client application (Comet) then terminates. If the user chooses to wait, then the client application waits until the approximate Wakeup time, before submitting the file request again.