com.jme3.network.base
Class KernelAdapter

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

public class KernelAdapter
extends java.lang.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


Nested Class Summary
 
Nested classes/interfaces inherited from class java.lang.Thread
java.lang.Thread.State, java.lang.Thread.UncaughtExceptionHandler
 
Field Summary
 
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
 
Constructor Summary
KernelAdapter(DefaultServer server, Kernel kernel, MessageListener<HostedConnection> messageDispatcher, boolean reliable)
           
 
Method Summary
 void broadcast(Filter<? super Endpoint> filter, java.nio.ByteBuffer data, boolean reliable, boolean copy)
           
 void close()
           
protected  void connectionClosed(Endpoint p)
           
protected  void createAndDispatch(EndpointEvent event)
           
protected  void createAndDispatch(Envelope env)
           
protected  void dispatch(Endpoint p, Message m)
          Note on threading for those writing their own server or adapter implementations.
protected  void flushEvents()
           
protected  HostedConnection getConnection(Endpoint p)
           
 Kernel getKernel()
           
protected  MessageProtocol getMessageBuffer(Endpoint p)
           
 void initialize()
           
protected  void reportError(Endpoint p, java.lang.Object context, java.lang.Exception e)
           
 void run()
           
 
Methods inherited from class java.lang.Thread
activeCount, checkAccess, clone, countStackFrames, currentThread, destroy, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, stop, suspend, toString, yield
 
Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
 

Constructor Detail

KernelAdapter

public KernelAdapter(DefaultServer server,
                     Kernel kernel,
                     MessageListener<HostedConnection> messageDispatcher,
                     boolean reliable)
Method Detail

getKernel

public Kernel getKernel()

initialize

public void initialize()

broadcast

public void broadcast(Filter<? super Endpoint> filter,
                      java.nio.ByteBuffer data,
                      boolean reliable,
                      boolean copy)

close

public void close()
           throws java.lang.InterruptedException
Throws:
java.lang.InterruptedException

reportError

protected void reportError(Endpoint p,
                           java.lang.Object context,
                           java.lang.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 a 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 MessageProtocol 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 java.lang.Runnable
Overrides:
run in class java.lang.Thread