On Aug 10, 2007, at 8:35 PM, Emil Ong wrote:
> --- Compl Yue Still <[EMAIL PROTECTED]> wrote:
>
>> Hello Hessian Guys,
>>
>> I found the ideas of hessian rather excellent when choosing a wire
>> protocol for inter-component communications in a new open source
>> framework I'm starting.
>>
>> However after some investigation and initial work, I got an idea to
>> further compact the traffic by introducing a mechanism of constant
>> pool. This ideas comes from the class file format and runtime
>> handling of symbolic linkages in the JVM specification. Here in
>> hessian we can just maintain a runtime constant pool at each side
>> per connection, to store type names, map keys and other values
> those
>> can be treated as constants, and tends to be reused repeatedly over
>
>> time.
You're right that the type names and field keys can be compressed
from Hessian 1.0.
But Hessian 2.0 already does that. :)
Each map or list Type establishes an implicit reference (like the
object reference) and can be referred to in a following instance.
e.g. the first instance would be
M t x00 x08 qa.Hello
...
z
while a following one would look like:
M x75 x90
...
z
x75 is the type reference. The x90 is integer 0. A different type
might be x91, x92, etc.
In Hessian 2.0, objects can be compressed even more from the map to
avoid repeating the field names. The definition looks like:
O # object def implicitly creates ref like the object ref
x00 x08 qa.Hello # type
x92 # number of fields
x06 fieldA
x06 fieldB
The instance refers to the definition and can avoid the field and
type entirely:
o x90 # refers to object def #0 since x90 is integer 0
x05 Hello # string data for fieldA
x95 # integer data for fieldB
>> I suggest a
>> C object
>> notation to add an object to the constant pool at both sides, at
>> the next free index, and later the notation
>> p b32 b24 b16 b8
>> can be used to reference the constant value by its index, where a
>> value is expected. This is somewhat like how ref is handled.
There are a few difficulties with this specific notation.
First, Hessian 2.0 already saves list instances, object instances,
object definitions, and types. So the only largish types left
unsaved are strings and binary data.
More importantly, because Hessian is a single-pass serialization
protocol, it's not possible for Hessian to know if an object or
string will be reused. The def/ref pattern essentially implies a
two-pass serialization, which we definitely want to avoid.
In the case of the .class file, the Java compiler knows every single
string, double, method, etc that's used in the .class before it
begins writing out the data. So it doesn't need to rely on
heuristics to guess which objects will be used and can be a bit more
efficient.
>>
>> I can see reasoning why this mechanism is not included in current
>> specification of hessian that the web-service nature implies most
>> connections are short-lived so such a mechanism makes little sense
>> in bandwidth saving, besides the complexity it will bring.
>>
>> However I don't know if long-connections commonly exist in current
>> hessian world, at least my scenarios would be like so, and I think
>> it might be similar when short hessian connections are pooled for
>> reuse over time. In such cases I suppose the constant pool would
>> same even more bandwidth than the compaction by spec version 2.0,
>> considering long (java) type names and overly used field names.
Since it's related, there is a "streaming" mode for Hessian 2.0.
(The 'P' message introduces it.)
After each top-level object in the stream, the object reference map
is reset (see Hessian2Input.resetReferences()). However, the type
map and the object-definition map are not reset in streaming mode.
So in long-lived Hessian streams, the type names and field names are
only sent once, which is what you're looking for.
-- Scott
>>
>> What is your evaluation, does it worth to be added to the protocol?
>
> Hi Compl,
>
> This is a pretty interesting idea. I would rephrase it as adding
> instance references rather than constants. Scott, what do you think?
>
> There are a couple of possibilities in the meantime. Basically the
> compression you're suggesting is like an explicit form of gzip (sort
> of), so you could just use gzip for your application now. The other
> thing we've got going is a Hessian/REST implementation that features
> caching for HTTP GETs. That would reduce processing time in certain
> applications.
>
> Thanks for the suggestion!
>
> Emil
>
> ============================================================
>
> Emil Ong
> Software Engineer
> Caucho Technology, Inc.
> Tel. (858) 456-0300
> mailto:[EMAIL PROTECTED]
>
> Caucho: Reliable Open Source
> --> Resin: application server
> --> Quercus: PHP in Java
> --> Hessian Web Services
>
>
> _______________________________________________
> hessian-interest mailing list
> [email protected]
> http://maillist.caucho.com/mailman/listinfo/hessian-interest
_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest
