Class C4Socket

  • All Implemented Interfaces:
    Direct Known Subclasses:
    AbstractCBLWebSocket, MessageSocket

    public abstract class C4Socket
    extends C4NativePeer
    The process for closing one of these is complicated. No matter what happens, though, it always ends like this: Java calls C4Socket.closed (in the JNI, this turns into a call to c4socket_closed, which actually frees the native object). Presuming that the C has a non-null C4SocketFactory reference and that it contains a non-null socket_dispose reference, the C invokes it, producing the call to C4Socket.dispose

    I think that this entire class should be re-architected to use a single-threaded executor. Incoming messages should be enqueued as tasks on the executor. That would allow the removal of all of the synchronization and assure that tasks were processed in order.

    Note that state transitions come from 3 places. Neither of the two subclasses, MessageSocket nor AbstractCBLWebSocket, allow inbound connections. For both, though shutdown is multiphase.

  • Core: core request open and can request close
  • Remote: this is a connection to a remote service. It can request shutdown
  • Client: the client code can close the connection. It expects never to hear from it again