Class KernelAdapter

java.lang.Object
java.lang.Thread
com.jme3.network.base.KernelAdapter
All Implemented Interfaces:
Runnable

public class KernelAdapter extends Thread
Wraps a single Kernel and forwards new messages to the supplied message dispatcher and new endpoint events to the connection dispatcher. This is used by DefaultServer to manage its kernel objects.

This adapter assumes a simple protocol where two bytes define a (short) object size with the object data to follow. Note: this limits the size of serialized objects to 32676 bytes... even though, for example, datagram packets can hold twice that. :P

  • Constructor Details

  • Method Details

    • getKernel

      public Kernel getKernel()
    • initialize

      public void initialize()
    • broadcast

      public void broadcast(Filter<? super Endpoint> filter, ByteBuffer data, boolean reliable, boolean copy)
    • close

      public void close() throws InterruptedException
      Throws:
      InterruptedException
    • reportError

      protected void reportError(Endpoint p, Object context, Exception e)
    • getConnection

      protected HostedConnection getConnection(Endpoint p)
    • connectionClosed

      protected void connectionClosed(Endpoint p)
    • dispatch

      protected void dispatch(Endpoint p, Message m)
      Note on threading for those writing their own server or adapter implementations. The rule that a single connection be processed by only one thread at a time is more about ensuring that the messages are delivered in the order that they are received than for any user-code safety. 99% of the time the user code should be writing for multithreaded access anyway.

      The issue with the messages is that if an implementation is using a general thread pool then it would be possible for a naive implementation to have one thread grab an Envelope from connection 1's and another grab the next Envelope. Since an Envelope may contain several messages, delivering the second thread's messages before or during the first's would be really confusing and hard to code for in user code.

      And that's why this note is here. DefaultServer does a rudimentary per-connection locking but it couldn't possibly guard against out of order Envelope processing.

    • getMessageBuffer

      protected MessageBuffer getMessageBuffer(Endpoint p)
    • createAndDispatch

      protected void createAndDispatch(Envelope env)
    • createAndDispatch

      protected void createAndDispatch(EndpointEvent event)
    • flushEvents

      protected void flushEvents()
    • run

      public void run()
      Specified by:
      run in interface Runnable
      Overrides:
      run in class Thread