tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shields, Dorwin T." <DShie...@Paymentech.com>
Subject RE: HTTP Tunneling using Tomcat
Date Fri, 17 Mar 2000 20:53:48 GMT
All I would recommend you use KeepAlive--your
webserver should leave the socket connections
open if it supports Keepalive--you'll need a
client that also supports Keepalive...not sure
if the JDK's URLConnection does or not so, you
may also want to look at the HTTPClient package
if you are doing a lot of posting to a webserver:
   http://206.14.202.69/java/classes.html
follow the Version 0.3-2 link.  There is a table
of differences between this and URLConnection at:
  http://206.14.202.69/java/HTTPClient/urlcon_vs_httpclient.html

Dorwin

-----Original Message-----
From: Gerard Monsen [mailto:gerim@legalvista.com]
Sent: Friday, March 17, 2000 6:58 AM
To: tomcat-user@jakarta.apache.org
Subject: HTTP Tunneling using Tomcat


      Does anyone here know of any way to create a constant
socket connection through HTTP?  I had thought there might
be a way through servlets.  It seemed all I had to do was get
the ServletInputStream and ServletOutputStream and never
close them.  I could then theoretically write to and read from
the streams for as long as I wanted.
      Unfortunately, this doesn't seem to work and all of the
documentation and books on servlets I've seen only concentrate
on the request/response model for servlets.  I'm getting
the idea that what I'm looking for may not be possible because
of the way HTTP was designed, but I'm wondering if perhaps
someone here had found a way to get around that.
      We want to do this for three reasons:

1.  We want the constant socket connection for speed purposes,
and so that as new information comes to the server, it gets sent
to the client right away.

2.  We want the connection to run through our secure https server
so that all communications are encrypted with SSL.  As an added
bonus, this means that all of the encryption will be done with faster
native code (the SSL server on the server, the browser code on
the client).  We can't use Sun's encryption mechanisms, because
they cause SecurityException's in untrusted applets.

3.  Most importantly, it gets around any potential problems with
firewalls.

       Any help you can give would be most appreciated.

Gerard Monsen
Integrated Litigation Solutions
Oakland, CA


--------------------------------------------------------------------------
To unsubscribe, email: tomcat-user-unsubscribe@jakarta.apache.org
For additional commmands, email: tomcat-user-help@jakarta.apache.org

Mime
View raw message