tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: HOW TO: create custom Tomcat 6 connector to do port sharing
Date Thu, 30 Jun 2011 10:26:41 GMT
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:aw@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message