Resynchronizing

Network connections can go bad, hosts can go down, interfaces can be taken down and processes can stop functioning.

In the case of the xmtopas protocol, such situations usually result in one or more of the following:

Missing packets
Resynchronizing requests

Missing packets

Responses to outstanding requests are not received, which generate a timeout. That's fairly easy to cope with because the data-consumer program has to handle other error return codes anyway. It also results in expected data feeds not being received. Your program may want to test for this happening. The proper way to handle this situation is to use the RSiClosex function to release all memory related to the dead host and to free the RSI handle. After this is done, the data-consumer program may attempt another RSiOpenx to the remote system or may simply exit.

Resynchronizing requests

Whenever an xmtopas daemon hears from a given data-consumer program on a particular host for the first time, it responds with a packet of i_am_back type, effectively prompting the data-consumer program to resynchronize with the daemon. Also, when the daemon attempts to reconnect to data-consumer programs that it talked to when it was killed or died, it sends an i_am_back packet.

It is important that you understand how the xmtopas daemon handles “first time contacted.” It is based upon tables internal to the daemon. Those tables identify all the data-consumers that the daemon knows about. Be aware that a data-consumer program is known by the host name of the host where it executes suffixed by the IP port number used to talk to the daemon. Each data-consumer program running is identified uniquely as are multiple running copies of the same data-consumer program.

Whenever a data-consumer program exits orderly, it alerts the daemon that it intends to exit and the daemon removes it from the internal tables. If, however, the data-consumer program decides to not request data feeds from the daemon for some time, the daemon detects that the data consumer has lost interest and removes the data consumer from its tables as described in Life and Death of xmtopas. If the data-consumer program decides later that it wants to talk to the xmtopas daemon again, the daemon responds with an i_am_back packet.

The i_am_back packets are given special treatment by the RSI interface. Each time one is received, a resynchronizing callback function is invoked. This function must be defined on the RSiOpenx subroutine.

Note: All data-consumer programs can expect to have this callback invoked once during execution of the RSiOpenx subroutine because the remote xmtopas does not know the data consumer. This is usual and should not cause your program to panic. If the resynchronize callback is invoked twice during processing of the RSiOpenx function, the open failed and can be retried, if appropriate.