Sometimes a lot of the things you want to do start to all have some core things in common. Recently, several of my pet projects (those nobody is as yet paying for) have all but cried out for back end server functionality. I've been needing something that stays running to maintain a cache of information and connections, but wanted it to be lightweight and simple. Sure, it could all be done with servlets and web services on a j2ee platform but the weight and ownership issues, not to mention deployment just bug me.

I personally think we (as an industry) have taken to over using standardized interfaces like web services and servlet calls. The infrastructures required are just too costly in terms of manpower, dedicated hardware, and in some cases licensing.

I've been working a lot in Eclipse again -- specifically in the Eclipse Java IDE. Over the last couple of days I've created a "Generic Server". What I mean by that, is that I've created a set of classes which can be invoked simply to begin listening on a given TCP Port. This generic server will accept "n" simultaneous connections, and hand each off to a waiting pool of "handler" threads. The handler threads themselves are also generic in that they don't really care what traffic they handle. Each handler will wait for session to be handed to it, then will listen for an inbound command. For my generic purposes, I've defined commands to mean a single string of text, delimited by a newline character. The handler will wait for "s" seconds for such a command before dropping the connection. Once a command is read, the command itself is passed to a method called "handleCommand()" which is meant to be overloaded in each use of the "generic" server. A few other public methods include "sendData" -- which sends data back through the connection, and "endSession" which as you'd imagine drops the session.

That works fine if whatever you're wanting to serve is fairly simple -- you get a command, possibly with a parameter, then you send a response and return control to the handler to wait for another command or end the session. What if you want more? In particular, what if a command is received that starts a more complex process during which the server side needs to request something from the client side? To meet this need I added a method called sendRequest() which sends back a string to the client side, then awaits a response of up to "n" bytes, with a specific timeout period and a specific delimiter (both passed as parameters to the method). In other words, I could issue a request for a password, and await up to 30 bytes terminated by a null character or newline.

By spending almost three days doing the development work on this core set of generic functionality, I now have the basis for any number of utility backend needs which are on my list of pet projects. On top of that, I can deploy my little server on just about any java enabled device. The complete byte code is less than 8k -- less if I deploy it as a jar file. I'm not restricted to running on someone's J2EE server. I can run many instances of it on the same machine with different ports -- though I shouldn't need to, as both the thread pool size and the connection queue are configurable.

The minimal protocol definitions I've made include an end session signal from either end to avoid having to time out on connections, but just for testing I did a lot of work with one or both sides failing to send that signal just to make sure that the server side wasn't susceptible to easy flood attacks, and to make sure the client and server both handled situations where the queue was full gracefully. In scale tests, using an assumption that a short session for data retrieval of some kind would last between 1 and 3 seconds, it handled being hit with 500 concurrent requests for a period of over an hour without any difficulty, and never push my processor past 3% (which means I got the thread locking about right).

So, the long and short of it is that now I have this great generic server -- it serves nothing, but it scales really well!