geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stolz <mst...@pivotal.io>
Subject Re: New client/server protocol - seeking feedback
Date Mon, 02 Oct 2017 17:22:00 GMT
We should check that it is actually safe to add fields.
If it isn't we're likely to have a lot of versioning to do.

--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771

On Mon, Sep 25, 2017 at 5:25 PM, Galen O'Sullivan <gosullivan@pivotal.io>
wrote:

> Replies inline.
>
> On Mon, Sep 25, 2017 at 12:13 PM, Udo Kohlmeyer <ukohlmeyer@pivotal.io>
> wrote:
>
> > Replies inline
> > On Mon, Sep 25, 2017 at 11:21 AM, Dan Smith <dsmith@pivotal.io> wrote:
> >
> > > This actually brings up another point I was going to ask about. I don't
> > see
> > > any version information in the protocol. How will we handle adding new
> > > features to this protocol? Do the clients and servers negotiate which
> > > version of the protocol to use somehow?
> > >
> > > I think there should be a plan in place for making changes to the
> > protocol
> > > and supporting old clients. Given that, we shouldn't add fields that
> > aren't
> > > actually used into the existing version of the protocol. When we
> > introduce
> > > new features into the protocol, that's the point at which we should add
> > the
> > > fields to support that feature.
> > >
> >
> > [UK] - Protobuf allows for the amending of messages. As soon as the
> > protocol changes significantly the "magic" number will have to be
> > incremented, indicating a new (non-backward compatible) version of the
> > protocol. This of course has bigger problems, where Java does not allow
> for
> > multiple versions of the same class to be loaded, so a server could run
> > only 1 version of Protobuf messages at a time.
> >
>
> We have to be careful about how we extend protobuf messages, though. I'm
> not sure exactly what's safe to do, but it should at least be safe to add
> fields (assuming they don't change existing behavior -- we'll have to think
> about this) and ignore old fields (which is how you would remove a
> now-unused field). It's fairly simple to add new operations without any
> interesting breakages - they'll fail with older servers and not be sent
> with older clients. I think adding new operations is a pretty good way to
> add features that don't require a real rework of the protocol. For those
> that do, we can version the initial byte.
>

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