Discussions

News: xSocket 1.2 released - NIO library

  1. xSocket 1.2 released - NIO library (9 messages)

    xSocket 1.2 has been released. xSocket is a easy to use NIO-based library to build high performance, highly scalable network applications. It supports writing client-side applications as well as server-side applications in an intuitive way. Issues like low level NIO selector programming, connection pool management, connection timeout detection or fragmented buffer reads are encapsulated by xSocket. xSocket supports TCP (incl. SSL) and UDP. One of the largest changes to 1.2 is the introduction of the Stream I/O SPI. This service provider interface allows replacing the build-in low-level NIO module by other I/O implementations. Provider implementations based on grizzly and MINA are under development. Would you be able to use this library? Where would you use it?
  2. Looks nice. I like the usage simplicity... BTW, in the light of emergence of JMX would be nice if socket server would expose some of its metrics and cfg over JMX MBeans so that one can monitor it in a standard JConsole... http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
  3. JMX support already exists[ Go to top ]

    JMX is already supported. By calling MultithreadedServerMBeanProxyFactory.createAndRegister(myServer, "MyTestServer") the metrics will be exposed. See xSocket tutorial - chapter JMX
  4. Interesting.. Does it retain the asynchronous, non-blocking behaviour of NIO (so it doesn't fall into being another unscalable Socket implementation)? Does it support providing your own custom threading model? I think those two issues are the most important ones. NIO is great in theory, unfortunately its API's are somewhat counter-intuitive at times, making it harder than necessary to use..
  5. Asynchronous, non-blocking behaviour of NIO is supported by xSocket on the client-side and on the server-side (see NonBlockingConnection class). Threading is configurable based on the java.util.concurrent.Executor implementation, which can be set outside.
  6. First of all MINA is also a good NIO implementation. From the performance view there shouldn’t be big differences. The major difference is the key abstraction. xSocket works on Connections for stream-based communication (TCP) and Endpoints for packet-based communication (UDP). By using MINA you would work on handlers and (in most cases?) on messages. For a simple TCP-based server based on MINA (see the MINA echo server example), you would have to implement a handler, to receive the incoming message (a ByteBuffer), work on it (may be based on former ByteBuffers if more than an echo should be written), and write the response message (ByteBuffer or array of ByteBufffers) by using a session instance. By using xSocket you would also have a handler to be notified, but you would only work on a connection object, which represents the underlying (TCP) connection instance. That means data will be written and read by using methods of the connection object. A connection also supports convenience methods like methods to read data which is scattered over several ByteBuffers (readStringByDelimiter would be a typically example for this). Beside performance issues a major goal of xSocket is to allow intuitive programming.
  7. First of all MINA is also a good NIO implementation. From the performance view there shouldn’t be big differences.
    Thanks for mentioning Apache MINA (http://mina.apache.org/), and I am glad to hear that MINA provider implementation is planned.
    The major difference is the key abstraction. xSocket works on Connections for stream-based communication (TCP) and Endpoints for packet-based communication (UDP). By using MINA you would work on handlers and (in most cases?) on messages.

    For a simple TCP-based server based on MINA (see the MINA echo server example), you would have to implement a handler, to receive the incoming message (a ByteBuffer), work on it (may be based on former ByteBuffers if more than an echo should be written), and write the response message (ByteBuffer or array of ByteBufffers) by using a session instance.

    By using xSocket you would also have a handler to be notified, but you would only work on a connection object, which represents the underlying (TCP) connection instance. That means data will be written and read by using methods of the connection object. A connection also supports convenience methods like methods to read data which is scattered over several ByteBuffers (readStringByDelimiter would be a typically example for this). Beside performance issues a major goal of xSocket is to allow intuitive programming.
    I agree with you that working with connections in a blocking manner helps more intuitive programming. Apache MINA project team is reviewing possible candidate solutions to add blocking (or non-flooding) I/O support to MINA without compromising its API design philosophy. I think the strongest power a user get from MINA is 'protocol codec', which brings separation of concerns between business logic and protocol encoder/decoder. We keep working on providing various ways to implement various protocols via ProtocolCodecFilter extension as easily as possible, and I believe our coverage will increase over time.
  8. Asynchronous, non-blocking behaviour of NIO is supported by xSocket on the client-side and on the server-side (see NonBlockingConnection class).

    Threading is configurable based on the java.util.concurrent.Executor implementation, which can be set outside.
    Configurable based on Executor? Hmm.. In what way? Does this mean I can use in-memory queues, for instance having one thread doing accepting, another one reading, a pool of threads processing, and a final one writing back? Or is the connection just passed to the Executor pool of threads and expected to be processed by it, with "configurability" being in setting the number of threads?
  9. xSocket uses internal in-memory queues to read and write data. Reading and writing data will be done within the Selector thread. The worker threads will be used (if not single threaded mode is activated) to call the handler’s event notification methods. Within the callback method the application-specific processing is done. xSocket implements a architecture, close to Architecture of a Highly Scalable NIO-Based Server
  10. Mina[ Go to top ]

    How does it compare to Mina? .V