Excuse me if I'm wildly off-base here, since I haven't yet digested all this, but I figured I'd contribute some general info about network connections in Tomcat (and webapps) that might possibly help.
First of all, the primary responsibility of a web application server is to serve HTTP requests, and an HTTP request consists of a definite cycle where the client sends a request, the server builds a response, sends it, and the listens for the next request (typically several threads worth of that process running in parallel). Therefore, you should never make the primary request process wait on ANY sort of activity (other than short-lived things like file or database I/O). Otherwise you stall the processor threads, and if you do it enough time, end up running out of processor threads entirely.
I think that was understood here, but I'm trying to be complete and explicit. Any extraneous port-parking needs to be done by an auxiliary thread, not the main request thread, and since the main request thread shouldn't return to idle with resources hanging off of it (child threads), the auxiliary threads need to be launched and maintained outside the request-response environment (that is, by an init() method in a
servlet, or some similar mechanism).
Secondly, the Core Servlet class is a generic listener/handler all by itself. It can be used (directly or as a base class) for other things besides HTTP requests, although I've not seen anyone actually do so. But that's why it's a parent of HttpServlet instead of HttpServlet being self-contained. So there's a possibility there.
Thirdly, Tomcat is an expandable architecture. It might be worthwhile to make this auxiliary service be an independent engine bolted on to the Tomcat framework instead of having to re-invent the functionality and architecture yourself. That's especially true should you decide to use the Servlet class as your basis.
So much for listening ports and mechanisms. As far as sessions go, that's a little trickier. The HttpSession is a transient object created and maintained for the benefit of a particular client/server conversation. Since HTTP is a series of "one-off" request-response cycles, the Session is a way to make what would otherwise be stateless be stateful. In the case of the normal web process, the session has an ID that keys into the session storage within the server and attaches the session and its related objects to a given request based on that key so that clients and their sessions are properly matched up. The session ID is provided either as an appendage to the outgoing URL or in a cookie (or sometimes both places).
Because the session is created and destroyed within the context of a web application, it's not really reliable for use anywhere else. The session may be timed out and invalidated by the HTTP/JEE Server, not created yet, or even explicitly destroyed by the primary webapp. Furthermore, there's no API to obtain the session ID (which is proper, since it's not supposed to be meddled with outside of the J(2)EE API), nor is there a guaranteed way for extra-webapp code to resolve that ID into a Java HttpSession object. All the more so, since in extreme cases, that might require fetching the session data and reconstructing the session object from serial storage in the case of servers running clustered or doing session "paging".
So if you want to tie a webapp and an independent serving process together neatly and reliably, you'll need to provide your own mechanism.
