{Proposal} Control Protocol: Protocol Upgrade

[Sharvil Nanavati]

Summary:

This proposal contains two control packets. These packets can be used
to upgrade the standard control protocol to one that is more
extensive. The new control protocols always extend the original
protocol and all applications must support at least the original
control protocol.

Rationale:

The existing control protocol is good but has room for improvement.
This proposal provides a mechanism for two parties to negotiate an
upgrade to a newer control protocol. Subsequent proposals will
describe extended control protocols.

Packets:

Packet Name: Upgrade Protocol Request
Packet: 0x00 0x90 <requestedVersion (4)>
requestedVersion:
0 - no upgrade
1 - Extended Control Protocol 1

Packet Name: Upgrade Protocol Reply
Packet: 0x00 0x91 <acceptedVersion (4)>
acceptedVersion:
0 - no upgrade
1 - Extended Control Protocol 1

Usage:

The "Upgrade Protocol Request" packet may be sent only once by either
party. If both parties send the request simultaneously, they must both
reply with the same protocol version they had requested. Once an
"Upgrade Protocol Reply" message is sent, both parties may use packets
from the negotiated version.

The acceptedVersion field in the "Upgrade Protocol Reply" packet must
be no greater than (i.e. <=) the requestedVersion field in the
"Upgrade Protocol Request" packet. A version of 0 indicates that
control protocol extensions are not supported at all.

[Sharvil Nanavati]

There hasn't been any feedback on this proposal while there has been
for ECP1. Since ECP1 relies on this proposal going through, I'm going
to assume that everyone is satisfied with this proposal.

If there aren't any major objections before Monday, July 14, we'll
accept this proposal and release it as an official protocol extension.
In the meantime, it would be great to see some sort of feedback on
this even if it's just along the lines of, "This sounds good to me."

On Jul 5, 6:38 pm, Sharvil Nanavati <Sharvil.Nanav...@gmail.com>
wrote:

[Chris "Cerium" Rog]

Is it safe to assume that most additions we make from now until quite
a long time from now are going to be ECP1? How often do you think we
will be extending it? Also, is there any reason that the protocol
version deprecates previous versions? Since we're mandating that our
extensions are backwards compatible, why not just have our packet
denote the "most extended" packets?

[Sharvil Nanavati]

Here's how I see it working: the ECP1 proposal is standalone. If we
want to make additions to it, we do so before we approve it. Once it's
approved, we cannot extend ECP1 and we will have to build ECP2 (which
will be a superset of ECP1). We need to have clearly defined versions
that won't change on you once you implement an approved specification.
As a developer, the last thing I would want is someone to say, "Oh
yeah, your implementation is no longer compliant because we changed
the spec."

I don't think we will be extending the control protocol frequently. I
expect that over time, we'll move towards TCP-ish behaviour (and we
see that already with the flow control in ECP1's window size packet)
but it'll only happen when the need arises or when we see a simple
solution to decrease the overhead. I don't expect any work on ECP2 for
months, if not more.

It's possible that we may have to deprecate old packets because we
found a better way to perform the same task (or our needs changed and
the old packet can't satisfy them). It's safe to deprecate packets but
it's unsafe to remove them (i.e. you must implement the handlers for
deprecated packets as well).

I don't think we should tie version numbers to something like a packet
ID. If we do so, we're forced to monotonically increase packet IDs and
we might run into a lot of trouble with that in the future. There
might be a good reason to leave a gap in packet IDs and then fill them
in later with a newer ECP but we don't know that yet. At this stage,
we don't have the foresight to give guarantees on a packet ID
allocation policy so I think it's still best to use a logical version
number as we have right now.

[Chris "Cerium" Rog]

Do we need to even change packet ids? The client/server will know the
packet id and will know what version of the protocol the other end is
using. At that point it can just use whichever version of that packet.
If it hasn't been extended into the current version, fall back a
version. Not implemented there either? Fall back again. Eventually
this would continue bubbling until the most recent implementation was
found or until it reached the original packet structure.

[Sharvil Nanavati]

It's possible to reuse packet IDs for operations that are nearly
identical but have minor semantic differences. The fact still remains,
though, that we'll need to introduce new packets from time to time and
we can't guarantee an allocation order that's monotonically
increasing.

Are we ready to approve the spec?

[Cerium]

That's good with me.

[Sharvil Nanavati]

Fantastic, I've uploaded a new file called asss-1.4.4-control-protocol-
upgrade.patch that adds support for this extension to ASSS 1.4.4. At
present, it negotiates version 0 (no upgrade). The patch should be
applied in the asss/src directory as follows:

patch -p0 < asss-1.4.4-control-upgrade-protocol.patch

When I implement ECP1, I will generate a new patch that builds on top
of this one.

[Sharvil Nanavati]

I just noticed that the packet handlers need to be thread-safe. I've
updated the patch file to take that into account.

On Jul 16, 11:15 pm, Sharvil Nanavati <Sharvil.Nanav...@gmail.com>
wrote: