.. _disconnected-operation: ###################### 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 :ref:`rlm-init` 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.