tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob DeRemer <>
Subject RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Date Thu, 30 Jun 2011 01:19:03 GMT
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.


-----Original Message-----
From: André Warnier [] 
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?


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:
For additional commands, e-mail:

View raw message