Hello Geodes! Good discussion on what/how the messages will be/handled once a connection is established.
+1 to a simple initial handshake to establish version/supported features that client/server will be communicating. >From what I've seen so far in the proposal it is missing a definition for the "connection"/disconnect messages. - expected to see it here: https://cwiki.apache.org/confluence/display/GEODE/Generic+System+API >From a protocol perspective, this is currently a pain point for the geode-native library. As Jake mentioned previously, having messages that are class-like and have a singular job helps client developers by having an explicit protocol to follow. The basic case a developer is going to exercise is to connect/disconnect. How to do this should be straightforward from the start. Geode probably does not need a 7 Layer OSI stack, but it might make sense to have a couple layers: 1 - transport (network socket) 2 - protocol (version/features) 3 - messaging (do cluster work) e.g. client library opens a socket to the server (layer 1 - check) client/server perform handshake and the connection is OPEN (layer 2 - check) pipe is open for business, client/server do work freely (layer 3 - check) When this is sorted out I think a couple simple sequence or activity diagrams would be very helpful to the visual-spatial folks in the community. Best, Ernie ps. one consideration for message definition might be to use a more tabular presentation of messages followed by any definitions/cross-referencing... this is an example from a CDMA protocol I have worked with in the past Location assignment message Field Length (bits) MessageID 8 TransactionID 8 LocationType 8 LocationLength 8 LocationValue 8 × LocationLength 1. MessageID The access network shall set this field to 0x05. 2. TransactionID The access network shall increment this value for each new LocationAssignment message sent. LocationType The access network shall set this field to the type of the location as specified in Table [image: page144image36968] [image: page144image37392] [image: page144image37976] [image: page144image38560] [image: page144image38984] [image: page144image39408] On Mon, May 8, 2017 at 7:48 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 >
