Package com.couchbase.lite.internal.replicator

Class AbstractCBLWebSocket

  • All Implemented Interfaces:
    AutoCloseable
    Direct Known Subclasses:
    CBLWebSocket
    public abstract class AbstractCBLWebSocket
extends C4Socket
    First of all, you need to know about ProtocolTypes. Core knows all about the WebSockets protocol. It would be glad to be pretty much completely responsible for a WS connection, if we could just send the bytes across some raw byte stream. For better or worse, though we hired OkHTTP for this job. It is also very smart and *it* wants to handle the WS connection. The solution, dating back to the dawn of time, is that we *always* use what Core, quite oddly, calls MESSAGE_STREAM protocol. In this mode Core hands us only minimal state transition information and the basic payload data that must be transferred. The comments in c4Socket.h are incredibly valuable.

    So, some assumptions. If you are here:

    • you are talking MESSAGE_STREAM.
    • there are no inbound connections
    This class is just a switch that routes things between OkHttp and Core. Core does its callbacks via the abstract methods defined in C4Socket and implemented here. OkHttp does its callbacks to the CBLWebSocketListener which proxies them directly to Core, via C4Socket. The peculiar factory method returns an instance of the concrete subclass, CBLWebSocket. There are different sources for that class, one for each of the (CE/EE x platform) variants of the product.

    State transition: Things kick off when Core calls openSocket. We are now in the state CONNECTING. In response, we ask OkHttp to open a connection to the remote. In the happy case, OkHttp successfully makes the connection to the remote. That causes a callback to CBLWebSocketListener.onOpen. We proxy that call to Core. The connection is now OPEN. After that, the two sides chat. If Core has something to say, we get a call to send(). We proxy that call to OkHttp, and, when the data has been sent, call back to Core with completedWrite(). If the remote has something to say, we get a call to one of the two CBLWebSocketListener.onMessage() methods and proxy the content to Core by calling received() Eventually, someone decides to close the connection. If it is the remote, we get a call to CBLWebSocketListener.onClosing(). We proxy that to Core, which, surprisingly, turns right around and proxies it back to us, by calling close(). If it is Core that decides to close the connection, we get a call to requestClose(). That should result in a call to CBLWebSocketListener.onClosed().

    This class is going to cause deadlocks. While C4Socket does not synchronise outbound messages (Core to remote) this class does. Messages headed in either direction (to or from core) seize the object lock (from C4NativePeer). If message processing seizes any other locks, the two lock may be seized in the opposite order depending on which way the message is going. This invites deadlock.

    • Field Detail

    • Method Detail

      • addKeyManager

        public static int addKeyManager​(@NonNull
                                KeyManager keyManager)

      • close

        public void close()

      • getOkHttpSocketFactory

        @NonNull
public final okhttp3.OkHttpClient getOkHttpSocketFactory()