On Fri, May 5, 2017 at 2:09 PM Hitesh Khamesra <hitesh...@yahoo.com> wrote:
> > 0. In first phase we are not doing chunking/fragmentation. And even this > will be option for client.( > https://cwiki.apache.org/confluence/display/GEODE/Message+Structure+and+Definition#MessageStructureandDefinition-Protocolnegotiation > ) > 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. -Jake
