Auto-Starting the RTserver

Before looking in more details at some of the fault tolerant features of TIBCO SmartSockets, you first need to stop any RTservers and RTclients that are still running.

Step 1

Stop the RTserver and any RTclients that are running

Type in the following command at the operating system prompt. Note that if you have already changed to the Lesson 6 directory, the rtserver -stop_all command fails to find any rtserver.cm file and you’ll get an error.

$ rtserver -stop_all 
. 
. 
. 
TAL-SS-00088-I Connecting to project <rtworks> on <_node> RTserver 
TAL-SS-00089-I Using tcp protocol 
TAL-SS-00088-I Connecting to project <rtworks> on <_node> RTserver 
TAL-SS-00089-I Using tcp protocol 
TAL-SS-00091-I Message from RTserver: Connection established. 
TAL-SS-00096-I Start subscribing to subject </_sunsoft_196> 
TAL-SS-50004-I RTgms is not currently running 
TAL-SS-00099-I Sending RTserver stop message 
TAL-SS-00100-I Message from RTserver: All RTservers and clients 
stopping. 
Message from RTserver: All RTservers and clients stopping. 

This command causes a process to start up that sends a message to the RTserver to shut down all RTservers and all RTclients that are currently running.

Step 2

Copy the send.c, send.cm, receive.c, and receive.cm files

Copy send.c, send.cm, receive.c, and receive.cm into your working directory. Under Windows copy the makefiles sendw32m.mak and recvw32m.mak into your working directory. Use the command chmod 777 * to allow write access to the sample programs you copy.

This send.cm file stores the commands executed by the sending program. The receive.cm program is a file of commands executed by the receiving program.

Step 3

Compile and link the send.c and receive.c programs

Compile and link the send.c and receive.c programs in different windows.

At the current time you should have no RTservers running.

Step 4

Start the receiving program

$ receive.x 

$ run receive 

$ receive 

You should see output similar to this:

Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using tcp protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
/* Here you see the RTclient auto-starting RTserver */ 
Attempting auto-start of RTserver. 
. 
. 
. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
Message from RTserver: Connection established. 
Start subscribing to subject </lesson6/receive>. 

Note that the process first tried to connect to RTserver, and when that failed, the process auto-started an RTserver. The default behavior of an RTclient is not to try to auto-start RTserver if it is unable to locate an RTserver. However, because you may want RTclients to be able to do this, you can modify this behavior by using a Start Prefix on the logical connection name specified in the Server_Names option.

The default start prefix is start_never. To allow RTclients to auto-start RTservers, change this to start_always. You will see that receive.cm has this change. See Logical Connection Names in Chapter 4, Publish-Subscribe, of the TIBCO SmartSockets User’s Guide for more details.

Step 5

Start the sending program

With RTserver and the receiving program running, start the sending program in another window:

 $ send.x 

$ run send 

$ send 

You should see output similar to this:

Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
Message from RTserver: Connection established. 
Start subscribing to subject </lesson6/send>. 
Sending message 1 
Sending message 2 
Sending message 3 
... 

The receiving program starts to print out the messages in the window where it is running.

Message Count = 1 
Message Count = 2 
Message Count = 3 
... 

Now let’s see what happens when you shut RTserver down while both the sending and receiving programs are running.

Step 6

Shut down the RTserver

In a new window, shut down RTserver with this command:

$ rtserver -stop_servers 

Look at the output in the windows where the sending and receiving programs are running when the RTserver is stopped. Output similar to this is displayed:

In the sending window:

Sending message 19 
Sending message 20 
Sending message 21 
WARNING: Lost connection to RTserver: error code = 10. 
Attempting to reconnect to RTserver. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using tcp protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
Attempting auto-start of RTserver. 
. 
. 
. 
RTserver started successfully. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
Message from RTserver: Connection established. 
Start subscribing to subject </lesson6/send> again. 
Sending message 22 
Sending message 23 
Sending message 24 
... 

In the receiving window:

Message Count = 19 
Message Count = 20 
WARNING: Lost connection to RTserver: error code = 10. 
Attempting to reconnect to RTserver. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
Connecting to project <smartsockets> on <_node> RTserver. 
Using tcp protocol. 
connect: Connection refused 
Could not connect to <_node> RTserver. 
Attempting auto-start of RTserver. 
. 
. 
. 
bind: Address already in use 
RTserver cannot be started.  There appears to be an RTserver 
running already (the conn <local> is already in use). 
Connecting to project <smartsockets> on <_node> RTserver. 
Using local protocol. 
Message from RTserver: Connection established. 
Start subscribing to subject </tutorial/lesson6> again. 
Start subscribing to subject </lesson6/receive> again. 
Message Count = 22 
Message Count = 23 
Message Count = 24 
... 

This example illustrates that both clients detected almost instantly that the RTserver was no longer present, and both tried to restart it. In this example, the sending program was the one that restarted RTserver. Even though it took several seconds to restart RTserver, only a single message was lost in the transition. It may happen when you try this exercise that no messages are lost. If you wish to absolutely ensure that no messages are lost, then you need to use TIBCO SmartSockets guaranteed message delivery features, which are covered later in this lesson.

To get the receiving program to successfully reconnect to RTserver when the connection is broken, ensure that TipcSrvMainLoop is called in a loop like this:

while (1) { 
    TipcSrvMainLoop(T_TIMEOUT_FOREVER); 
} 

The reason for this is that when the connection is broken (by stopping RTserver), the function TipcSrvMainLoop exits. Thus, you need to make sure you return to it to get the desired behavior to restart and reconnect to RTserver. See TipcSrvMainLoop in the TIBCO SmartSockets Application Programming Interface reference for more details.

Step 7

Stop all running processes

Stop all the running processes with this command:

$ rtserver -stop_all