Disconnected Operation

Sometimes it is necessary to support many thousands of clients connected to the license server. If your customers generally will have more than 5,000-10,000 client applications using licenses at the same time, you might want to use RLM’s disconnected operation capabilities. Reprise does not recommend using disconnected operation if your customers generally have a relatively small number of clients in use at any one time.

To utilize RLM disconnected operation, call the alternate initialization routine rlm_init_disconn() in place of rlm_init(). rlm_init_disconn() takes 4 parameters – the first 3 are the same as rlm_init(), and the fourth is a promise of how often you will contact the server by calling rlm_get_attr_health(). The rlm_init_disconn() call is described in the rlm_init(), rlm_init_disconn() section.

RLM disconnected operation works much the same as permanent connections up to the point of the first checkout. Once the license is checked out, however, RLM will disconnect the client from the license server. Each subsequent call to rlm_checkout(), rlm_checkin() or rlm_get_attr_health() will re-establish the connection to the server, send the appropriate message, read the response, then disconnect again.

There are several considerations to keep in mind if you use disconnected operation:

Heartbeats are slower. In normal operation, the first heartbeat is sent immediately after the first checkout, then each call to rlm_get_attr_health() reads the heartbeat response, which should be waiting to be read, then sends the next heartbeat. In this way, the client never has to wait for a round trip to the server. With disconnected operation, however, the client must establish a new TCP/IP connection to the server, send a message, and read the reply.
A handle set to disconnected operation cannot be later set to use permanent connections. If you require a permanent connection to the license server, call rlm_init() and create a new handle.
Since the client is disconnected, the RLM server cannot send reverse heartbeats to the client, and does not receive notification if the client exits from TCP/IP. This means that the license will be held on the server side for the promise interval from the last time the client contacted the server, even if the client has exited. The license server will also time out the disconnected client and clean up their data structures if it has not heard from the client within the promise interval.
Since disconnected operation is used by ISVs with large numbers of connected clients, the minimum interval at which you can contact the server is larger. Whereas for connected handles, the minimum heartbeat interval is 30 seconds, for disconnected operation, it is 10 minutes. This also means that the minimum promise interval is 10 minutes.

Note

Reprise Software recommends setting promise to at least 20 minutes to avoid unintended license removal by the license server.
Pay particular attention to the relationship between the minimum heartbeat interval and your promise: rlm_get_attr_health() can be called as often as you like, but it will not communicate with the server if it was called less than 10 minutes earlier. So, for example, if you have a promise of 15 minutes, and you call rlm_get_attr_health every 9 minutes, you will not talk to the server for 18 minutes (since the first call will not communicate, and the 2nd will happen 18 minutes after the last call that did communicate). In this example, you will have exceeded your promise, and the server may time out your application and forget about you. (We say “may” because it depends on when the server actually does the timeout processing, which is not precise, since it only does this processing every 5 minutes).
The license server processes timed-out clients every 5 minutes. This is not synchronous with your checkout request, however, it is every 5 minutes from when the server started.
If you plan to check any licenses in then close the handle (i.e., if you are not going to use the handle after checking a license in), then you should omit the rlm_checkin() call, and simply call rlm_close() on the handle. rlm_close() always checks-in any licenses which are checked out on the handle, and by only calling rlm_close() RLM will only reconnect to the server one time for all your licenses as well as to tell the server that you’re are done with the handle.

Notes on Disconnected Operation for RLM

We performed some tests on an Intel Solaris server. Our results indicate the following:

In our testing (non-shared licenses on a 2007-vintage server machine), the license server is capable of processing ~100 transactions/second with a load of 10k clients.
At 25k clients, the server can process 50 transactions/second, and at 50k clients, 35-40 transactions/second.
To first approximation, a transaction can be either a checkout or a heartbeat.

What does this mean to you when designing your product checkout/heartbeat strategy?

Let’s say you have a product with an average usage time of 20 minutes (1200 seconds). If you want your server to support 50k clients, this implies a (steady-state) checkout rate of 42 checkouts/second. From the above, you can see that this is as many transactions as the server can process, leaving none for heartbeats, so this is not a realistic expectation. Also, if there is a large burst at certain times of the day, the server might well get so overloaded that client requests time out.

A more practical limit might be 25k clients or less. At 25k clients, the sustained checkout rate is 21/second. If you set the heartbeat interval to 20 minutes as well, the heartbeat rate would be 21/second (actually, it would be less, since some clients would exit before ever generating a heartbeat), making the total transaction rate at the server 42/second, which would leave the server with some headroom for slight bursts of activity. If you tried to send heartbeats every 10 minutes, however, the server could do little more than process heartbeats (at 42/second) from the 25k clients. Again, you would have to consider checkout rates at peak demand times of the day.