>> Thank Constin,that really helped. Are there any
>> advantages of WARP over APJ? I mean why would I want
>> to use one over the other?
I could tell you that packet encoding in ajp13 and warp
is very similar.
Did there is advantages to use warp over ajp ?
Hard to tell but the question is elsewhere, advantage of
mod_warp over mod_jk.
mod_warp use warp protocol, require Apache Portable Runtime
and is known to works under Apache 1.3/2.0
original mod_jk, 1.1 in tomcat cvs, and 1.2 in jakarta-tomcat-connectors
cvs works with all major webservers (Apache 1.3/2.0, IIS, NES/iPlanet/Domino)
So using jk instead of warp depend on webserver you want to have it.
If need today, or tomorrow IIS/NES/DOMINO, use mod_jk, if you only
need to use Apache 1.3/2.0 and have APR ready, you can use also mod_warp.
Using mod_warp implies also you have tomcat 4.x as servlet engine, whereas
mod_jk via ajp13 support tomcat 3.2, 3.3, 4.x. If you have today TC 3.2/3.3
and plan to upgrade at a later time to tomcat 4.x, mod_jk is the preferred
choice.
Another point is load-balancing/fault-tolerance. If you want to built tomcat
farms behind your web server, mod_jk is the good choice, mod_warp didn't support
that feature today.
>I don't like either - the only reason I use ajp13 is
>backward compatibility and the fact that all versions of
>tomcat supports it.
yep
>Ok, the history is a bit complicated, it started with
>ajp11 and ajp12 ( first text based, second binary ).
>Ajp12 evolved into ajp13 - using same encoding but with some
>extensions ( to deal with persistent connections ).
>
>Looking back - and forward - I think using CDR or XDR would
>have been ( or will be ) much better choices for marshalling,
>and a subset of RPC or IIOP for protocol. Jk2 supports multiple
>protocols, and one of the reasons is to allow a future
>migration to a more standard protocol.
I take a look at XDR (didn't know where to find info about CDR).
ajp13 is very similar to XDR, and even less bd/cpu cosuming
since XDR want to have 4 bytes (32bits) padded messages whereas
ajp13 could use only single byte. Why waste cycle to send unused
bytes and waste cycles to decode unused bytes. ;)
>We're not the only one inventing protocols - look at DCOP :-)
>And it seems full IIOP ( or at least using an existing ORB ) does
>have performance impact, or did for KDE people.
Yes, it's clear that a full protocol like IIOP/DCOM is something
like using a tank to kill a fly, at least in 99% of time operation
which is to forward request and replies.
The current marshalling/unmarshalling is really similar to what
XDR provide (data type are : smallint (16bits), int (32ints),
strings, raw datas (opaque data in XDR), boolean), enums like
headers type are present as smallint). Maybe we could add
small strings à la MacOs/Pascal ( strings of less than 256 chars),
having there first byte indicating length) and also add hyperint
(64bits).
But one thing I'd like to see in future ajp, is the unmarshalling
of headers, ie separate reply headers datas from reply datas.
It will help in web-server side to works on such headers, determine
and alter some of them.
>Plus
>it would not easily allow the kind of transports we are using
>or want to use ( unix sockets, JNI, doors, etc ).
yes
>However using a minimal subset ( we only deal with strings,
>ints, arrays of string and very simple method calls ) would
>eliminate most of the confusion and maybe even provide more
>interoperability. Anyway - ajp13 is here to stay - but
>I hope it'll be the last binary protocol we invent for
>jk.
ajp13 is perfect for the current works, ie forwarding request/replies
(just need to add some headers packets separated from data packets).
It's fast, but need to be extended (that's the ajp14 goal), to allow
authentification, configuration informations and better error
handling between web-server and tomcat servers.
May be we could/should add doc on ajp13 format like the one in
XDR (RFC 1832) :
----
1. AJP13 DATA TYPES
Each of the sections that follow describes a data type defined in
AJP13, shows how it is declared in the language, and includes
a graphic illustration of its encoding.
For each data type in the language we show a general paradigm
declaration. Note that angle brackets (< and >) denote
variablelength sequences of data and square brackets ([ and ]) denote
fixed-length sequences of data. "n", "m" and "r" denote integers.
For the full language specification and more formal definitions of
terms such as "identifier" and "declaration", refer to section 2:
"The AJP13 Language Specification".
For some data types, more specific examples are included. A more
extensive example of a data description is in section 3: "An Example
of an AJP13 Data Description".
1.1 Byte and Unsigned Byte
We defines 8-bit (1-byte) numbers called byte and unsigned byte.
Ranges are [-128,127] for Byte and [0,255] for Unsigned Byte.
They are represented in two's complement notation.
Their declarations:
byte identifier; unsigned byte identifier
+-------+
|byte 0 |
+-------+
<-8 bits>
BYTE
UNSIGNED BYTE
1.2 Short Integer and Unsigned Short Integer
We also defines 16-bit (2-byte) numbers called short
integer and unsigned short integer. Their representations are the
obvious extensions of byte and unsigned byte defined above.
Ranges are [-32768,32767] for Short Integer and
[0,65535] for Unsigned Integer.
They are represented in two's complement notation. The most and
least significant bytes are 0 and 2, respectively. Their
declarations:
short identifier; unsigned short identifier;
(MSB) (LSB)
+-------+-------+
|byte 0 |byte 1 |
+-------+-------+
<----16 bits---->
SHORT INTEGER
SHORT UNSIGNED INTEGER
1.3 Long Integer and Unsigned Long Integer
We also defines 32-bit (4-byte) numbers called long
integer and unsigned long integer. Their representations are the
obvious extensions of short integer and unsigned short integer
defined above.
Ranges are [-2147483648,2147483647] for Long Integer and
[0,4294967295] for Unsigned Long Integer.
They are represented in two's complement notation. The most and
least significant bytes are 0 and 3, respectively. Their
declarations:
long identifier; unsigned long identifier;
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |
+-------+-------+-------+-------+
<------------32 bits------------>
LONG INTEGER
LONG UNSIGNED INTEGER
1.4 Hyper Integer and Unsigned Hyper Integer
The standard also defines 64-bit (8-byte) numbers called hyper
integer and unsigned hyper integer. Their representations are the
obvious extensions of integer and unsigned integer defined above.
They are represented in two's complement notation. The most and
least significant bytes are 0 and 7, respectively. Their
declarations:
hyper identifier; unsigned hyper identifier;
(MSB) (LSB)
+-------+-------+-------+-------+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+-------+-------+-------+-------+-------+-------+-------+-------+
<----------------------------64 bits---------------------------->
HYPER INTEGER
UNSIGNED HYPER INTEGER
1.5 Enumeration
Enumerations have the same representation as short signed integers.
Enumerations are handy for describing subsets of the integers.
Enumerated data is declared as follows:
enum { name-identifier = constant, ... } identifier;
For example, the three colors red, yellow, and blue could be
described by an enumerated type:
enum { SC_A_CONTEXT= 1, SC_A_SERVLET_PATH= 2, SC_A_REMOTE_USER = 3 } reqattrs;
It is an error to encode as an enum any other integer than those that
have been given assignments in the enum declaration.
1.6 Boolean
A boolean is a 8-bit datum that encodes the TRUE FALSE with the
0x01 (TRUE), 0x00 (0x00) values
boolean identifier;
+-------+
|byte 0 | BOOLEAN
+-------+
<-8 bits>
1.7 Variable-length Opaque Data
The standard also provides for variable-length (counted) opaque data,
defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
to be the number n encoded as an unsigned integer (as described
below), and followed by the n bytes of the sequence.
Byte m of the sequence always precedes byte m+1 of the sequence, and
byte 0 of the sequence always follows the sequence's length (count).
Variable-length opaque data is declared in the following way:
opaque identifier<m>;
or
opaque identifier<>;
The constant m denotes an upper bound of the number of bytes that the
sequence may contain. If m is not specified, as in the second
declaration, it is assumed to be (2**32) - 1, the maximum length.
The constant m would normally be found in a protocol specification.
For example, a filing protocol may state that the maximum data
transfer size is 8192 bytes, as follows:
opaque filedata<8192>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 |
+-----+-----+-----+-----+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|
VARIABLE-LENGTH OPAQUE
It is an error to encode a length greater than the maximum described
in the specification.
1.8 String
We defines a string of n (numbered 0 through n-1) ASCII
bytes to be the number n encoded as an unsigned short integer (as described
above), and followed by the n bytes of the string and ending with a trailing
0 (zero) as for C Strings.
Byte m of the string always precedes byte m+1 of the string, and byte 0 of the
string always follows the string's length. Counted byte strings are declared as
follows:
string object<m>;
or
string object<>;
The constant m denotes an upper bound of the number of bytes that a
string may contain. If m is not specified, as in the second
declaration, it is assumed to be (2**16) - 1, the maximum length.
The constant m would normally be found in a protocol specification.
For example, a filing protocol may state that a file name can be no
longer than 255 bytes, as follows:
string filename<255>;
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+
| length n |byte0|byte1| ...| n-1 | 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+
|<-2 bytes-->|<-------------n bytes + 1------------->
STRING
It is an error to encode a length greater than the maximum described
in the specification.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
