Package com.jme3.network.base

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

Nested Class Summary

Nested classes/interfaces inherited from class java.lang.Thread

Thread.State, Thread.UncaughtExceptionHandler

Field Summary

Fields inherited from class java.lang.Thread

MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY

Constructor Summary

Constructors

Constructor	Description
KernelAdapter(DefaultServer server, Kernel kernel, MessageProtocol protocol, MessageListener<HostedConnection> messageDispatcher, boolean reliable)

Method Summary

Modifier and Type	Method	Description
void	broadcast(Filter<? super Endpoint> filter, 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 MessageBuffer	getMessageBuffer(Endpoint p)
void	initialize()
protected void	reportError(Endpoint p, Object context, Exception e)
void	run()

Methods inherited from class java.lang.Thread

activeCount, checkAccess, clone, countStackFrames, currentThread, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, onSpinWait, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, start, stop, suspend, toString, yield

Methods inherited from class java.lang.Object

equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Constructor Details

KernelAdapter

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

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