1. Protocols

Currently WebSemaphore supports HTTPS and WebSockets protocols. More protocols and standards are considered.

2. HTTPS

When used over HTTPS, the requestor sends a request to acquire a semaphore either synchronously or asynchronously.

• In asynchronous mode, the message will be received and stored in WebSemaphore until delivered to the client. The processing endpoint must be decoupled and accessible to WebSemaphore via an ip / domain.
• In synchronous mode, the response is a straighforward http response with a confirmation of lock acquisition or rejection.

3. Websockets

Websockets allow us to achieve all the benefits of a REST connection. Since websockets are bidirectional, both client- and server-side applications can take both the roles of requestor and processor.

• In asynchronous mode websockets have the advantage to perform a callback to a client that is not accessible over HTTP due to firewalls or lack of public IP address.

• In synchronous mode websockets still operate in a partially asynchronous manner since the protocol does not provide an immediate response mechanism and it must be sent as a separate message to the client.

• Websockets lock requests are currently coupled with the websocket session id and lock acquisition/rejection signals are only communicated to that session. Since sessions are unique, a server restart or a page reload may leave orphan lock requests in waiting or acquired state.

  Orphan Waiting messages may be dropped rather safely if the client session is gone

  Orphan Acquired lock capacity must change ownership or be released when the client session is gone [UPCOMING]