Very well stated and completely understood. My gut is already telling me that trying to customize/extend Tomcat in this way is way outside the scope of how Tomcat was designed or intended to be used. And, I would bet you're right with regard to parts of the Tomcat architecture having certain "HTTP expectations".
Thanks again for your risk assessment - this will help in making our decision on how to move forward. -bob -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, June 30, 2011 6:27 AM To: Tomcat Users List Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing Hi. To round up what I am trying to say : Tomcat is a java servlet engine. In the principle, there is nothing that says that it cannot handle protocols other than HTTP/HTTPS, and run servlets which handle other kinds of messages than HTTP/HTTPS messages. However, my general impression is that 1) this is not being done very often 2) therefore, even apart from the Connectors, there may be quite a few aspects in Tomcat which are HTTP(S)-centric, and which have not really been investigated a lot with non-HTTP(S) messages. For example, there was a discussion recently on this list, concerning "HTTP 100 Continue" status codes, and if I remember correctly this implied that a Listener should be configured at the level of the Connector, and it also implied that this would trigger the immediate parsing of request headers as soon as a request came in. Now I can quite easily imagine that this could be much more complicated if some requests which come in, are non-HTTP(S). In summary, I have the feeling that creating a "discriminating Connector" which would dispatch HTTP(S)/XMPP requests as appropriate, could just be the tip of the iceberg, and that you could find yourself sucked into making many more changes than what you imagine at first. Now take this with a grain of salt, since I am neither a java nor a Tomcat expert. I just happen to remember the classic line which says that "90% of a software project is done in 90% of the time; the remaining 10% also." Bob DeRemer wrote: > Hi Andre, > > Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well. > If we're able to share a port, it solves various IT administration issues > when deployed in corporate environments. In addition, it will enable us to > have a single server process and ultimately a simpler overall architecture > because we won't have to configure/manage 2 separate server applications. > > I'm still not sure this is feasible or the best way to go, but it's worth the > investigation. Given a lot of work I've done on the Microsoft side of > things, their WCF infrastructure provides a TCP port sharing service, which > is somewhat similar in nature to what we're looking to do. At the end of the > day - both HTTP and XMPP are TCP-based. So, if I can front a single port for > the incoming TCP request and then route it to the appropriate > protocol-specific endpoint, there would be some significant benefits to us > architecturally because we are not forced to break the functionality into 2 > separate applications - unless we wanted to. > > That said, if I can find a solution, we'll have to validate the performance > and stability - no doubt. > > Thanks, > Bob > > -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Wednesday, June 29, 2011 3:30 PM > To: Tomcat Users List > Subject: Re: HOW TO: create custom Tomcat 6 connector to do port > sharing > > Pid wrote: >> On 29/06/2011 19:51, Christopher Schultz wrote: >>> Honestly, I'd look for a non-Tomcat-centric solution because it's >>> probably already been built elsewhere. >>> >>> -chris >> Why is opening another port a problem? >> > > +1 > > I do not know XMPP, but from the original OP description it sounds > like a protocol which uses its own transport protocol, and normally > some other standard port than 80/443. (*) > > Without even going into what kind of issues you may encounter at the Tomcat > level when trying to process requests/responses which are not HTTP/HTTPS, I > would also think that if you mix 2 different protocols on the same port, you > will be forcing whatever equipment/software which separates and dispatches > them, to look *inside* each TCP packet to determine which protocol this one > is about. That in itself will introduce quite a bit of overhead. > > Then again, if the connection is (sometimes) over SSL, that would also > probably mean that the packets have to be decrypted, even before their > HTTP/XMPP nature can be discriminated. > > Looking at XMPP in Wikipedia, it looks like there is something called "XMPP > over HTTP transport". Is that what the OP has in mind ? > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
