Re: ZeroCopyInputStream behavior

2009-03-03 Thread aepensky

Thanks for the quick response...

So, to do an RPC implementation over a stream channel (e.g. TCP),
where the message length is being sent in advance of the message body,
the fastest way would still be
(1) allocate bytes[length]
(2) stream.read(bytes, length)
(3) message.ParseFromArray(bytes, length)


... assuming that memory allocation for a large message is not a
problem.

true?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: ZeroCopyInputStream behavior

2009-03-03 Thread Kenton Varda
On Tue, Mar 3, 2009 at 12:20 PM, aepensky apen...@gmail.com wrote:


 Thanks for the quick response...

 So, to do an RPC implementation over a stream channel (e.g. TCP),
 where the message length is being sent in advance of the message body,
 the fastest way would still be
 (1) allocate bytes[length]
 (2) stream.read(bytes, length)
 (3) message.ParseFromArray(bytes, length)


Yes.


 ... assuming that memory allocation for a large message is not a
 problem.


Careful about that assumption.  What happens if a malicious user sends you a
length of 2^31-1?  You should probably either put a cap on the length or
allocate many small blocks as you read the message.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---