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
