Examples with DefaultServer com.jme3.network.base.DefaultServer used on opensource projects

Example 1 with DefaultServer

use of com.jme3.network.base.DefaultServer in project jmonkeyengine by jMonkeyEngine.

the class Network method createServer.

/**
     *  Creates a named and versioned Server that will utilize both reliable and fast
     *  transports to communicate with clients.  The specified port
     *  will be used for both TCP and UDP communication.
     *
     *  @param gameName This is the name that identifies the game.  Connecting clients
     *                  must use this name or be turned away.
     *  @param version  This is a game-specific verison that helps detect when out-of-date
     *                  clients have connected to an incompatible server.
     *  @param tcpPort  The port upon which the TCP hosting will listen for new connections.
     *  @param udpPort  The port upon which the UDP hosting will listen for new 'fast' UDP 
     *                  messages.  Set to -1 if 'fast' traffic should go over TCP.  This will
     *                  completely disable UDP traffic for this server.
     */
public static Server createServer(String gameName, int version, int tcpPort, int udpPort) throws IOException {
    UdpKernel fast = udpPort == -1 ? null : new UdpKernel(udpPort);
    SelectorKernel reliable = new SelectorKernel(tcpPort);
    return new DefaultServer(gameName, version, reliable, fast);
}

Example 2 with DefaultServer

use of com.jme3.network.base.DefaultServer in project jmonkeyengine by jMonkeyEngine.

the class KernelAdapter method dispatch.

/**
     *  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.
     *
     *  <p>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.</p>
     *
     *  <p>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.</p>    
     */
protected void dispatch(Endpoint p, Message m) {
    // here.
    if (m instanceof ClientRegistrationMessage) {
        server.registerClient(this, p, (ClientRegistrationMessage) m);
        return;
    }
    try {
        HostedConnection source = getConnection(p);
        if (source == null) {
            if (reliable) {
                // If it's a reliable connection then it's slightly more
                // concerning but this can happen all the time for a UDP endpoint.
                log.log(Level.WARNING, "Recieved message from unconnected endpoint:" + p + "  message:" + m);
            }
            return;
        }
        messageDispatcher.messageReceived(source, m);
    } catch (Exception e) {
        reportError(p, m, e);
    }
}