RE: HTTP plus
OK - persistance has paid off :) I now have a little client that with a small HTTP header will connect with a servlet, and run a persistent "telnet" like session with it until either someone times out or decides to quit. The only requirement is that you initiate the connection with HTTP headers. And in 1.1 you have to use a "chunked" reply structure. if using 1.0 you don't (there might be a way around that in 1.1 too but I havn't found it :) PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP plus
At 09:42 2/28/2007, you wrote: Back to the original issue: sounds like you really need to develop your own connector to handle your proprietary protocol, rather than trying to twist one of Tomcat's HTTP or AJP connectors into doing your bidding. What we do is to be determined. What I want to do is sus out the *full*extent* of tomcat's capabilities so I know what I have to work with. We will build the (internal) sockets based protocol to optimize the abilities of what we have available :) I am interested in what you mean by "connector" by that do you mean an interface to route connections to a Tomcat managed application that will work in concert with it's thread pooling etc? Is their a special more controllable API that such connectors use to dispatch requests to servlets? Since I am working on an internal protocol in an enviroment where we also wish to use full HTTP1.1 for other URLs and interfaces into the same application(s), all the HTTP features are desired. The servlet development model, and the vast infrastructure it now is a part of, Deployers, IDE plugins, connectors, books, documentation, system loggers and monitors, developer administration, and people who know how to use all of it and other positive attributes are really fantastic assets, so we wish to leverage it as much as we can and not re-invent wheels. I will put whatever HTTP headers are required to make tomcat operate (seeking minimum compliment) but after the connection is made and routed to the proper servlet I want to drop back to a binary non-http protocol for the duration of the connection. And if possible it would improve our system architecture If I could respond to the client without having to manage a lot of session state before all the input is read (actually, before all of it is written by the client to its outgoing socket) and processed. but at least so far with reading and testing it seems the input side of the socket is killed before or when one starts writing output. If this can be controlled by HTTP headers, tomcat config, setting something in an object etc then this would be a way we could do it and I'm very VERY interested in the possibility. We have full control of the client that will be connecting directly to tomcat "worker" instances. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP plus
> From: Peter Kennard [mailto:[EMAIL PROTECTED] > Subject: Re: HTTP plus > > > Excuse the naivety but I thought you couldn't open a socket > > with J2EE. I was told (I think on this list) that you need > > to use a JCA to make the connection. > > If this is true I want to know about this. It's not true. You can use any Java APIs you want, including ones dealing with sockets. Just don't expect transaction management, pooling, etc., to be aware of what you're doing. Back to the original issue: sounds like you really need to develop your own connector to handle your proprietary protocol, rather than trying to twist one of Tomcat's HTTP or AJP connectors into doing your bidding. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Peter Kennard wrote: Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. Tomcat is not a full J2EE server, just servlets+JSP, so maybe it lets you do things which are verboten in J2EE? If this is true I want to know about this. I am so far under the impression if you needed to connect with another protocol in a servlet you could in essence (Worst case scenario) "write a server" inside a servlet using sockets. Well you can certainly make an HTTP request (to an arbitrary URL, including your own) from within a servlet, wait for the response, process it as you see fit and finally return it to the original requestor. Several of our apps do this. If you want to wrap a connection-based protocol in this way, you'll have to save socket info in session state. This works with database connections (although connection pooling is better practice). But that would require you write all the code to handle aborting startup/shutdown thread management etc etc. If I can have a "tweaked" protocol servlet as part of a multi-servlet application this would make a perfect model for the "gateway" type of application between HTTP and a non (exactly) HTTP protocol we are trying to support. Please clarify: are you aiming to wrap non-HTTP services as HTTP services, for HTTP clients only? I got the impression from another msg that you hoped to "hand off" an initial HTTP request to a telnet conversation, which could be tricky or impossible. Are you reinventing "HTTP tunneling"? http://en.wikipedia.org/wiki/HTTP-Tunnel Paul Singleton Can you "write a server" inside a servlet ?? PK At 06:46 2/28/2007, you wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: > If you don't want to deal with HTTP, you should > not use the Servlet API (which is the Java > abstraction of HTTP) at all. You can do the > indicated code with generic sockets, no need to > mind about Servlets altogether. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Singleton Jambusters Ltd tel: 01782 750821 fax: 08707 628609 VAT: 777 3904 85 Company no. 04150146 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Yes - I'm assuming J2ee facilities. At 06:57 2/28/2007, you wrote: That's certainly correct, raw socket communication is not J2EE. Peter didn't mention, however, that J2EE was a necessary precondition for his case. On the contrary, this communication with some binary messages sent over sockets cannot be made to fit in a J2EE environment easily, save these options with JCA which I don't know enough about. Georg Wayne Gemmell wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: If you don't want to deal with HTTP, you should not use the Servlet API (which is the Java abstraction of HTTP) at all. You can do the indicated code with generic sockets, no need to mind about Servlets altogether. Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. If this is true I want to know about this. I am so far under the impression if you needed to connect with another protocol in a servlet you could in essence (Worst case scenario) "write a server" inside a servlet using sockets. But that would require you write all the code to handle aborting startup/shutdown thread management etc etc. If I can have a "tweaked" protocol servlet as part of a multi-servlet application this would make a perfect model for the "gateway" type of application between HTTP and a non (exactly) HTTP protocol we are trying to support. Can you "write a server" inside a servlet ?? PK At 06:46 2/28/2007, you wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: > If you don't want to deal with HTTP, you should > not use the Servlet API (which is the Java > abstraction of HTTP) at all. You can do the > indicated code with generic sockets, no need to > mind about Servlets altogether. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
That's certainly correct, raw socket communication is not J2EE. Peter didn't mention, however, that J2EE was a necessary precondition for his case. On the contrary, this communication with some binary messages sent over sockets cannot be made to fit in a J2EE environment easily, save these options with JCA which I don't know enough about. Georg Wayne Gemmell wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: If you don't want to deal with HTTP, you should not use the Servlet API (which is the Java abstraction of HTTP) at all. You can do the indicated code with generic sockets, no need to mind about Servlets altogether. Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
I understand what you are saying, however that means you also have to
re-do all the "application management" system. Deployment,
connectors, management, adminstration, thread management, load
balancing, SSL key management and configuration and many many other
infrastructure pieces that can be leveraged to manage a large complex
system. This would be a huge project (ie: the scale of creating tomcat)
So if one wants to create a web adminstratable application that has
(one or more servlet "ports" that connect with other protocols). And
has web ports to handle HTTP requests into the same system. If you
*can* do it in tomcat it would be great. If those protocols are
somewhat "transaction" based then they would fit very well into the
servlet model. I am trying to sus out the potential.
Yes you can always write a complete application manager from scratch :)
I am trying to avoid it.
Peter K.
At 06:36 2/28/2007, Georg Sauer-Limbach wrote:
If you don't want to deal with HTTP, you should
not use the Servlet API (which is the Java
abstraction of HTTP) at all. You can do the
indicated code with generic sockets, no need to
mind about Servlets altogether.
Georg
Peter Kennard wrote:
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That is read in incomming "socket stream" and write something back
while reading in a way that takes advantage of the
connection. That is not being purely "transactionless" and
bypassing all the HTTP specific protocols after the header needed
to address the specific servlet.
PK
At 20:59 2/27/2007, you wrote:
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need
is a "service name" and a "path" to the servlet followed by two
newlines as the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X" being the service name and "/Z" being the path to the servlet.
On reply if "service()" if you write to the
response.getOutputStream() you are in essence writing directly to
the connected socket unfiltered.
At 18:32 2/26/2007, you wrote:
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: > If you don't want to deal with HTTP, you should > not use the Servlet API (which is the Java > abstraction of HTTP) at all. You can do the > indicated code with generic sockets, no need to > mind about Servlets altogether. Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
If you don't want to deal with HTTP, you should
not use the Servlet API (which is the Java
abstraction of HTTP) at all. You can do the
indicated code with generic sockets, no need to
mind about Servlets altogether.
Georg
Peter Kennard wrote:
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That is read in incomming "socket stream" and write something back while
reading in a way that takes advantage of the connection. That is not
being purely "transactionless" and bypassing all the HTTP specific
protocols after the header needed to address the specific servlet.
PK
At 20:59 2/27/2007, you wrote:
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need is a
"service name" and a "path" to the servlet followed by two newlines as
the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X" being the service name and "/Z" being the path to the servlet.
On reply if "service()" if you write to the
response.getOutputStream() you are in essence writing directly to the
connected socket unfiltered.
At 18:32 2/26/2007, you wrote:
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That is read in incomming "socket stream" and write something back
while reading in a way that takes advantage of the connection. That
is not being purely "transactionless" and bypassing all the HTTP
specific protocols after the header needed to address the specific servlet.
PK
At 20:59 2/27/2007, you wrote:
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need is
a "service name" and a "path" to the servlet followed by two
newlines as the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X" being the service name and "/Z" being the path to the servlet.
On reply if "service()" if you write to the
response.getOutputStream() you are in essence writing directly to
the connected socket unfiltered.
At 18:32 2/26/2007, you wrote:
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
I guess I'll answer my own question here after some testing and research That is: If you override the "service()" method on servelet all you need is a "service name" and a "path" to the servlet followed by two newlines as the "minimal" header. ie: X /Z\n\n for the most minimal header. "X" being the service name and "/Z" being the path to the servlet. On reply if "service()" if you write to the response.getOutputStream() you are in essence writing directly to the connected socket unfiltered. At 18:32 2/26/2007, you wrote: Was this last message of mine just too naive :) Should I break it into smaller parts? Still curious :) Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
