Jason's suggestion seems (to me) similar in concept to http tunneling, except in that case doesn't the client needs to be proxy-aware? If that is not an option (seems like it's not), that does complicate things a tad.
The "routing port manager" (uber-server-socket?) would need a way to map some kind of content pattern of the wire protocol (RMI, HTTP, etc) to a service/port. Like using Pushback streams (read enough bytes to ID the protocol, push them back, send the stream to it's proper destination via chained in/out streams/sockets. (maybe) dumb question: In that scenario, I am wondering how would you distinguish requests for two different HTTP-ish services (like jmx-html and jetty/tomcat requests), which both look like HTTP on-the-wire? Would this even be a problem, or would the web container stuff be separate. Of course, if each service uses a distinct wire protocol then the port router thing would seem to work. You'd still need some sort of way to 'educate' the router as to where the services are actually listening (config file, etc), unless they registered themselves, which I think is in line with Marc's idea. The only thing to watch out for is that I *think* with the proxy-type solution, you'll have twice the file descriptors open on the box with the additional sockets. That may or may not be a concern. I've had problems running out of FDs before. If you guys are swamped, I'd be glad to throw something together to prove the concept. I've got lots of socket code laying around, and I've been looking to give some back. Mike _________________________________________________________ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=12035 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
