>> 1) We've talked about specifying a response packet to
>indicate that the
>> engine (or the web server) doesn't recognize a packet sent
>over. This would
>> allow us much more flexiblity to add packet types to ajpv14,
>without having
>> to make ajpv15,16, etc.
>
>+1
>
>In other words - both ends should deal with unknown packets - maybe by
>sending back an "UNIMPLEMENTED" message.
Since AJP indicate size we could deal with unknow packets. But
if we negociate at startup the common protocol level, we must
avoid that situation.
I like the idea of reject cmd, +1
>
>> 2) What about specifying a separate, out of band control socket
>> connection? If the web server opened up two connections, 1
>for data, one
>> for control, then we could have much better communication
>from the engine to
>> the server (if it was shutting down contexts, for example).
>We could also
>> have a heartbeat without interfering with the data channel.
>
>I'm not sure - but I can see some benefits.
>
>Right now we have (almost) bidirectional communication - the
>protocol is
>based on message passing, and sort of "token"-based:
>each side sends a message, then waits for a message.
>
>The main reason for that is the single-threaded web server. (
>Apache1.3,
>maybe other servers ). It is a bit difficult to deal with 2
>connections in
>a single threaded env ( while keeping the code as simple as possible ).
>My feeling is that for most needs of a servlet container we
>can deal with
>the single socket protocol. I don't know any (major) use case
>or feature
>of tomcat that would require the second socket.
Argh, all the subtility is here.
Basically even if ajp13 is a bidirectional protocol,
it's a request/reply protocol since it's how a web
server function :
1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
2) WAIT FOR RESPONSE
3) GET RESPONSE AND FORWARD TO WEB-SERVER.
We could have a second socket for control but :
1) How did we share it in forked (apache 1.3) env ?
=> shared memory => MM or APR
2) Ditto in a threaded architecture (Apache 2.0)
at least in MPM mode (a forked child which will in turn thread
child), but again how did we info we other forked.
Also doubling the socket, will double the descriptors open
and will be a problem under heavy load.
In an HTTP architecture we need again to mix data (tons of
messages) with control (very low traffic). And so we need
to read for possible message at some time.
1) FORWARD REQUEST FROM WEB-SERVER TO SERVLET ENGINE
2) WAIT FOR END OF PREVIOUS REPLY AND EVENTUALLY ADMIN MESSAGE
3) GET ADMIN MESSAGE and evnetually RESPONSE
4) GET RESPONSE AND FORWARD TO WEB-SERVER.
The admin message could be send() in socket at any time and
will be handled when a request will came....
