>>> a. Now these two chunks will go continuous. >>They would appear continuous to the object serialization layer.
One benefit of messageHeader with chunk is that, it gives us ability to write different messages(multiplexing) on same socket. And if thread is ready it can write its message. Though we are not there yet, but that will require for single socket async architecture. ________________________________ From: Jacob Barrett <jbarr...@pivotal.io> To: dev@geode.apache.org Cc: Anthony Baker <aba...@pivotal.io> Sent: Thursday, May 4, 2017 12:48 PM Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal Sent from my iPhone > On May 4, 2017, at 12:03 PM, Hitesh Khamesra <hitesh...@yahoo.com.INVALID> > wrote: > > And len 0 would indicate end of the message? > > > a. Now these two chunks will go continuous. They would appear continuous to the object serialization layer. > > > b. If its PDX encoded then pdx header(1byte:pdxid 4byte:len 4byte:typeId) > requires size of all pdx serialized bytes. So we know "size" of data upfront > here. We could define the InputSource for the Value part such that InputSource.getLength() could return a known length or -1 if length is unknown. If length is reasonable then the object could be encoded with a single chuck of size InputSource.getLength() followed by a 0 chunk. Clients are likely dealing with domain objects where the serialize length is not known until serialization is complete. This would require buffering to get the length. Buffering adds heap pressure and latency. -Jake
