geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <>
Subject Re: [gemfire-dev] New Client-Server Protocol Proposal
Date Mon, 08 May 2017 14:48:48 GMT
On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra <> wrote:

> 0. In first phase we are not doing chunking/fragmentation. And even this
> will be option for client.(
> )

I highly suggest initial handshake be more relaxed than specific "version
number" or flags. Consider sending objects that indicate support for
features or even a list of feature IDs. At connect server can send list of
feature IDs to the client. The client can respond with a set of feature IDs
it supports as well as any metadata associated with them, say default set
of supported encodings.

> 1. Are you refereeing websocket/spdy? But I think we are talking almost
> same thing, may be push isPartialMessage flag with chunk length(Anthony's
> example below) ?

I am not sure what you mean here but if you are talking about layering a
channel protocol handler then I guess yes. The point is that each of these
behaviors should be encapsulated in specific layers and not intermixed with
the message.

> 2. That's the part of the problem. Even if you need to serialize the
> "String", you need to write length first and then need to write serialized
> utf bytes. We can implement chunked input stream and can de-serialize the
> object as it is coming (DataSerializable.fromData(ChunkedStream)).

Right, and in this case the length is never the length of the string, it is
the length of the byte encoding of the string. This is not known until the
encoding is complete. So by chunking we can write the length of smaller
buffers (from buffer pools) as the length of that sequence of bytes, the
last chunk terminated with length 0. Each of those chunks can be based to a
UTF-8 to UTF-16 transcoder to create the String.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message