Protocol sanity checking: Java-style or C++-style?

[David Nadlinger <co...@klickverbot.at>]

I'm currently polishing up my D Thrift protocol implementations, and I 
wonder what kind of sanity checks for the amount of data read I should 
implement.

The C++ implementation of the protocols allows setting a limit for 
container and string sizes via the container_limit and string_limit 
properties, presumably to avoid massive amounts of memory being 
allocated due to a broken size field in the received data. On the other 
hand, the Java TBinaryProtocol has checkReadLength() to set a limit on 
the total number of bytes read off the wire (which also adds a tiny bit 
of overhead to any read() call).

Do you have any tips which of those is more useful in real-world Thrift 
use cases, or other ideas about what I should implement for D?

Thanks,
David

Re: Protocol sanity checking: Java-style or C++-style?

[Toby Thain <to...@telegraphics.com.au>]

On 23/06/11 12:02 PM, David Nadlinger wrote:
> I'm currently polishing up my D Thrift protocol implementations, and I
> wonder what kind of sanity checks for the amount of data read I should
> implement.
> 
> The C++ implementation of the protocols allows setting a limit for
> container and string sizes via the container_limit and string_limit
> properties, presumably to avoid massive amounts of memory being
> allocated due to a broken size field in the received data. On the other
> hand, the Java TBinaryProtocol has checkReadLength() to set a limit on
> the total number of bytes read off the wire (which also adds a tiny bit
> of overhead to any read() call).

The Java client just committed a default limit of 16MB in the framed
transport.

https://issues.apache.org/jira/browse/THRIFT-1205


--Toby

> 
> Do you have any tips which of those is more useful in real-world Thrift
> use cases, or other ideas about what I should implement for D?
> 
> Thanks,
> David
>