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
