I think we should be presenting the current proposal as the API and message structure, as would be laid out in an IDL. This way, we can experiment with Protobuf, Thrift serialization, &c. for message structure without having to exactly specify the message structure. This will make designing a protocol easier and allow us to leverage existing serialization libraries. If we ever get into a totally and manually specified binary protocol, charts of binary representations will be useful, but for now I think using a library that takes care of serialization for us will make our lives much easier. I've made some changes (removing type data, removing RequestHeader and ResponseHeader) that should make the wiki pages clearer.
On Thu, May 4, 2017 at 2:14 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > 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. > > > > I wouldn't tackle that at this layer. I would suggest adding a layer > between the message and TCP that creates channels that are opaque to the > message layer above. The message layer wouldn't know if it was talking to > multiple sockets to the client or single socket with multiple channels. Though we haven't really discussed it explicitly, the new protocol is adding the correlationID in the expectation that at some point it will be possible to execute requests out-of-order. One alternative to correlationID if we had multiple channels would be to use one channel per message or set of (ordered) messages. This would be a bit expensive if we used separate sockets for each, but if we had channels built into the protocol, it would be fine. The other use of correlationID might be for retries or to check up on a message after some issue leading to a disconnect. However, we have the EventID for that. As far as I know, we don't have the async, out-of-order functionality yet. I believe that in the current protocol, messages are ordered and synchronous -- they only happen in the order they're sent, and each operation blocks for the previous one to finish (though you could use multiple connections to get similar functionality). Galen On Mon, May 8, 2017 at 2:55 PM, Ernest Burghardt <eburgha...@pivotal.io> wrote: > +1 William, an even better example - that kind of representation will make > it so much better/easier for geode users to implement against, regardless > of language. > > On Mon, May 8, 2017 at 2:48 PM, William Markito Oliveira < > william.mark...@gmail.com> wrote: > > > +1 > > > > I think I've shared this before, but Kafka also has good (tabular) > > representation for messages on their protocol. > > > > - https://kafka.apache.org/protocol#protocol_messages > > - https://kafka.apache.org/protocol#protocol_message_sets > > > > On Mon, May 8, 2017 at 4:44 PM, Ernest Burghardt <eburgha...@pivotal.io> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > -- > > ~/William > > >
