NBServer - FAQ

main | news | status | download | faq | gettingStarted | javadoc

NBServer is a framework that eases the development of superscalable TCP-based network services based on Java 1.4 platform. It provides a superscalable server framework, as well as utilities commonly needed with such servers (large memory buffer pools, non-blocking pipes, etc.)

No, it is not. However, NBServer can serve as a foundation for a superscalable HTTP server (as well as a superscalable FTP server, SMTP/POP3 server, or any other TCP-based protocol server). Right now we are working on a NBServer-based HTTP connector for Apache Tomcat.

More connections serviced concurrently. Typical Java based network servers serve one client on one thread. Since threads are expensive resources, once you have more clients than you can have threads, your server will unable to accept further connections. A non-blocking server can service many connections on a single thread, hence the limitation on number of threads won't affect the number of concurrent connections the server can handle.

It takes over much of the drudgery. It sets up handler threads, then recieves and dispatches events for you. You only have to write a protocol handler, which is much like an event handler for read and write operations. Next, it provides you with an implementation of a global memory pool, as well as an "endless" pipe for content buffering. While not downright obvious, these objects are essential for all but most trivial protocol implementations.

Your protocol will probably generate response to the client. Of course, whenever you want to write some bytes to the socket, it is possible that the socket buffer will be full, and you won't be able to write out the content your algorithm just produced. What do you do then? Block until the socket buffer becomes available? No, because that would miss the whole point of writing a scalable server - you just can't block waiting for a socket output buffer to become available. What you do is that you store those bytes into a FIFO buffer (that is, a pipe). Then, when you recieve a notification that the socket is ready to write, you transfer the bytes from that pipe to the socket. Now you are scared that you have to do all of this yourself? Of course you don't! The framework will do this for you: it will give you an OutputStream - you simply write content to it, and the framework takes care of piping the content to the socket at its own pace.

Having to buffer data is the tradeoff for not having to have one thread per connection.

You can also buffer client input - especially if you have to relay between non-blocking code and "legacy" code that works with blocking interfaces (like servlets, which use the blocking-idiom java.io.InputStream to read request bodies). Since you want to shield the blocking-style code from actually getting blocked, you have to buffer all of the input (i.e. all of the request body in a HTTP message) beofre you pass it on to be processed to the blocking-style code.

Yes it can. Eventually, you can even run out of memory if you don't configure your server accordingly to the expected load. However, NBServer uses another facility of JDK 1.4 - memory mapped files - to conserve RAM. When a pipe starts buffering, it will first use RAM buffers. If the pipe becomes large, it will switch from using RAM to using a memory mapped file. Yes, memory mapped files have somewhat slower access time than direct RAM buffers (altough the file cache of the operating system can significantly improve this) but the framework is engineered so that this does not create a performance bottleneck. If your pipe is large and therefore uses a memory-mapped file for storing content, this means that your server is producing content faster than the network can transfer it to the client. Therefore, your bottleneck in this case is the network, and not the local filesystem access. NBServer will balance buffers between RAM and a memory-mapped file. And with today's hard-disk drives, it shouldn't be a problem to allocate a 1 GB temporary file for buffering on a production system should a need arise...