Hi Trustin,

> [...]
> 
> We overrided read/writeClassDescriptor() of ObjectInput/OutputStream to 
save
> the bandwidth.  When a Java object is serialized, the descriptor of the
> object's class is serialized together.  The descriptor contains a lot of
> meta-information related with the class and it's huge comparing to the
> actual data we want to exchange because it contains long strings such as
> type name and field name.  It's sometimes ten times bigger, and then we 
are
> wasting 90% of bandwidth.  That's why we chose to override
> read/writeClassDescriptor() method.
> 
> Calling getObject() with explicit class loader specified might help you:
> 
> MyMessageToReceive m = buffer.getObject(
> MyMessageToReceive.class.getClassLoader());
> 
> Please let me know if this works for you.  Otherwise, we need to find a
> better solution.

I'll try this solution on the client side by providing a special class 
loader - maybe it works. If it does, I'll post my findings so that others 
may use object serialization with Eclipse RCP as well.

> 
> > My last question concerns the different default max object sizes in 
the
> > en- and decoder implementations - is there a reason why the encoder 
may
> > encode objects up to Integer.MAX_VALUE, but the decoder refuses 
anything
> > above 1MB? Are you aware of some known issues concerning memory
> > consumption if I set the max object size of the decoder to
> > Integer.MAX_VALUE as well?
> 
> 
> I thought decoder should be more restrictive in receiving a big object
> because of the rick of DoS attack.  That's all.  If there's consensus on
> changing the default value, we can change it, too.  :)

Ok, just what I thought. The default value is fine - I think a short note 
in the JavaDoc stating that the max object size in decoder is set to a 
lower value because of possible DoS attacks would be nice. The reason that 
this doesn't affect me directly at the object serialization level is 
because of the fact I use SSL with client certs and the SSL filter 
prevents connections with invalid certs prior of a possible DoS attack (or 
am I mistaken?).

Thanks for all your help!

Greetz,

Sven


Information contained in this message is confidential and may be legally 
privileged. If you are not the addressee indicated in this message (or 
responsible for the delivery of the message to such person), you may not copy, 
disclose or deliver this message or any part of it to anyone, in any form. In 
such case, you should delete this message and kindly notify the sender by reply 
Email. Opinions, conclusions and other information in this message that do not 
relate to the official business of Proximity shall be understood as neither 
given nor endorsed by it.

Reply via email to