License Recovery After a Network Interruption

If your application's connection to the license server drops and then comes back, what happens to the license it had checked out? The answer depends on which connection method you're using, and the difference matters when you're deciding how to configure licensing for your product.

This article covers the three connection methods available, whether each one can automatically recover an existing checkout, and how often you should expect to check in with the server for each.

At a glance

• rlm_init() over TCP (standard, always-connected). Does not auto-recover the same checkout; you must check in (if possible) and check out again. Health-check cadence: about 30 seconds.
• rlm_init_disconn() over TCP (disconnected operation). Auto-recovers the exact same checkout. Health-check cadence: about 10 minutes minimum.
• RLM Cloud (HTTPS). Auto-recovers automatically, built into the transport. Health-check cadence: no enforced minimum; about 30 seconds is a reasonable default.
• RLM Cloud (HTTPS) combined with rlm_init_disconn(). Don't combine these. See note below.

Standard connections (rlm_init() over TCP)

This is the default: your application holds an open connection to your license server for as long as it's running. If that connection drops (network blip, VPN hiccup, anything), there's no built-in way to pick back up on the same checkout once connectivity returns. Your application needs to check the license back in (if it still can) and check it out again fresh.

For most applications, this is fine. Health checks happen roughly every 30 seconds, so you'll get timely feedback about a dropped connection, and re-checking-out is a small, well-supported operation.

One thing to plan for: if your floating license pool is fully in use at the moment your application tries to check out again, that checkout can fail even though the interruption itself has cleared. This isn't specific to recovering from a network drop; it's the normal behavior of a fully allocated floating license pool. See our floating license timeouts KB article for how to configure timeouts so seats held by clients that never came back get freed up for others.

Disconnected operation (rlm_init_disconn() over TCP)

Disconnected operation is built for the opposite trade-off: it lets your application resume the exact same checkout after a network interruption, as long as it reconnects within the promise window you configured. The cost is cadence: health checks with disconnected operation happen on a much coarser interval, on the order of 10 minutes rather than 30 seconds.

This limit applies no matter how often your application calls the health check function. Calling it every few seconds won't get you a fresher answer: the real reconnect to the server only happens roughly once every 10 minutes, and every call in between simply returns the same status your application already had. If you need to know sooner whether a checkout survived an interruption, calling more frequently won't help; the actual state only updates once the client reconnects.

This mode is intended for deployments with very large numbers of concurrently connected clients (thousands or more), where checking in every 30 seconds per client would put unnecessary load on the license server. If that's not your situation, plain rlm_init() is usually the better fit.

RLM Cloud (HTTPS)

If you're licensing through RLM Cloud over HTTPS, you get the "resume the same checkout" behavior automatically, regardless of which init call you use. There's no separate setting to turn on. This is a property of how the HTTPS transport works: every health check is already a fresh, self-contained request that re-establishes your checkout on the server side, so there's nothing extra to configure and no risk of losing your seat during a brief gap in connectivity.

Because of this, there's also no fixed minimum interval between health checks the way there is for the TCP transports above. You can poll as often as makes sense for your application. Something in the neighborhood of every 30 seconds is a reasonable default if you don't have another reason to pick a different cadence.

Don't combine disconnected operation with RLM Cloud

Since RLM Cloud already behaves like disconnected operation under the hood, there's no reason to also call rlm_init_disconn() on an HTTPS/RLM Cloud license. It doesn't add anything, and we recommend against it. Use plain rlm_init() for RLM Cloud licenses and let the transport handle recovery on its own.

Choosing between them

• Small-to-moderate client counts, on-prem server: use plain rlm_init(). Simple, well-supported, and a dropped connection just means a fresh checkout.
• Large client counts, on-prem server: consider disconnected operation if 30-second health checks from thousands of clients would overload your server. You trade check-in granularity for the ability to resume an existing checkout.
• RLM Cloud: you don't need to choose. Recovery after a network interruption is automatic either way. Just don't layer disconnected operation on top of it.

‍