tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <hgo...@slib.fr>
Subject RE: Mod_jk v/s mod_webapp
Date Tue, 02 Apr 2002 12:51:30 GMT
>> 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message