Morten Bo Oelbye wrote:
I am really schrewed up in this server show.
I have tryed different suggestion. I do not know how to reuse the
response and request connections.
I end up with the same error.
java.lang.IllegalStateException: Write attempted after request finished
Websockets ? How to reuse inputstream and outputstream here?
Morten,
it sounds like the problem here is due to some lack of understanding of the HTTP protocol,
rather than of understanding of Tomcat and/or HTTP input/output streams.
The HTTP 1.0 protocol is basically built around the following sequence :
- client makes a TCP connection to the server
- server accepts that connection, and waits for more data coming in on it
- client sends a HTTP request on that connection
- server gets the HTTP request
- server processes the HTTP request and builds a response
- server sends the response over the connection
- server closes the connection
- client receives the response and does something with it
- client closes the connection to the server
then, if the client has more requests to send, start back at the beginning.
To the above, the HTTP 2.0 protocol adds one major thing : "keep alive"
connections.
What changes is that at the end of the first request, the server and client can decide not
to close the underlying TCP connection, but to keep re-using it :
- client sends a new request on the same connection
- server gets the HTTP request
- server processes the HTTP request and builds a response
- server sends the response over the connection
etc, for a certain number of requests, and/or until a certain time without new requests
has happened. Then the server closes the connection.
This "keep alive" thing was added for the purpose of making the dialog between client and
server a bit more efficient, by avoiding having to build a new TCP connection for each new
request, and then throwing it away each time at the end of the request.
But this is all still based on the basic idea of : one request/one response, then again a
request/response, then again...
And each request/response cycle is independent of any other before or after it. Each
request/response can be handled by a different application on the server (or a different
instance of the same application).
The point is, from the application point of view, its work is /finished/ when it has sent
the response to the one client request for which it came alive.
And so, for example, the server application cannot send multiple responses over the same
connection in response to a single client request. And the server application cannot
decide to send something to the client, without the client having first asked for it by
sending a new request.
(And that is probably why you are having problems when your application tries to send
additional data after it has already indicated that the previous response was finished.
It can no longer send data over that same outputstream, because that output stream was
closed - even if the underlying HTTP connection is "keep alive" and is still open).
Websockets is /another/ protocol, different from HTTP, and designed for allowing just the
things that HTTP does not allow : the client establishes a permanent connection with a
server application, and from then on they can both exchange "messages" back and forth,
without any particular order and for as long as they want, over that same connection.
And to make this usable with web servers, there exists a possibility to "upgrade" a HTTP
connection to a websocket connection :
- the client creates a normal HTTP connection to the server
- the server accepts this HTTP connection
- the client then sends a special HTTP request to the server, asking to "upgrade" this
HTTP connection to a websocket connection
- the server - if it is "websocket-capable", accepts this request, starts the
corresponding application, and "gives it" the TCP connection with the client.
From now on, this application instance and this corresponding connection are dedicated to
this client, for as long as it takes, and they can exchange messages on this connection
for as long as they want and in whatever order they want (and these messages take a form
described by the websocket protocol, no longer by the HTTP protocol).
For the application, it does no longer exchange data with the client in the form of HTTP
requests/responses, it does it in the form of websocket messages (and thus no longer via
HTTP request/response objects or HTTP input/output streams, but via other kinds of
websocket-specific calls).
From the webserver point of view, it is a bit as if the application and the client have
now "gone to another room" and are having their own private conversation in their own
websocket language, over their own private connection.
This is also why, on the base of your initial description of "ping-pong" exchanges between
client and server, some people here advised you to use "websockets", because it seemed to
be a better fit than HTTP for what you are trying to do.
But is for you to decide ultimately, and to read on the subject.
For example, start here :
http://tomcat.apache.org/tomcat-8.0-doc/web-socket-howto.html
and follow the various links to additional information.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
