[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tcf-dev] RE: TCF communication protocol versioning
|
I have seen protocol feature flags successful in other places,
especially if new features are introduced in a backward
compatible way such that it is well defined from the very
beginning what kinds of messages an "old" client is expected
to ignore.
For this "ignore" part, some protocols use packets with
length identification sent first. An old client may only
know how to interpret the first 20 or so bytes it knows
to interpret. If partner however sends 40 bytes then only
new clients will know how to interpret the follow-on bytes.
SSH / Sftp is one example of a protocol which evolved that way.
Protocol evolution can be looked up from the IETF RFC pages.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Burton, Felix
> Sent: Freitag, 20. März 2009 15:34
> To: thomas.e.hansen@xxxxxxxxx
> Cc: Oberhuber, Martin; dsdp-tcf-dev@xxxxxxxxxxx
> Subject: RE: TCF communication protocol versioning
>
> Hi Thomas,
>
> I agree with you that flexibility is very important and that
> there must be a way for the protocol to evolve. One way I
> can see that working is that both sides exchange hello
> messages containing information about the protocol version.
> Let's say we wanted to do some of the changes you imagined
> below, then the peer supporting this change would include a
> marker in the hello message to indicate support for this
> change. I see two ways of doing this 1) add a TCF version
> like "TCFv2", or 2) add a feature flag like "tcf_feat_xyz".
> If both side supports the save TCF version of feature then
> they would switch all traffic from the point to use that feature set.
>
> Does this sound sufficient to you? If not, could you
> elaborate on what is missing?
>
> Thanks,
> Felix
>
> > -----Original Message-----
> > From: thomas.e.hansen@xxxxxxxxx [mailto:thomas.e.hansen@xxxxxxxxx]
> > Sent: Friday, March 20, 2009 2:06 AM
> > To: Burton, Felix
> > Cc: Oberhuber, Martin; dsdp-tcf-dev@xxxxxxxxxxx
> > Subject: RE: TCF communication protocol versioning
> >
> > Hi Felix,
> >
> > Thanks for the answer.
> >
> > Regarding #1, we already added "v1.0" to our service names
> in order to
> > control versioning on the service level.
> >
> > However, my question is regarding the TCF protocol itself. Say, for
> > whatever reason, you would like to add a new field to the "C" packet
> > header; a timestamp for example. This could be solved by
> adding a new
> > message type, "Cx", and a standard error message to be used in cases
> > where "Cx" is not supported. This would probably work fine for small
> > and rare changes. But at some point in time it would become more and
> > more messy. And what if you wanted to redesign the TCF protocol
> > altogether? Maybe you find out that ASCII strings don't do
> the job and
> > unicode is better? Or messages should not start with the
> message type
> > field but a length (these are just imaginary examples). In
> these cases
> > both ends of the communication would have to agree about the
> > communication protocol, before the TCF communication was
> established,
> > and everyone would have to be upgraded to the new protocol.
> >
> > I don't know if this will ever be a real problem. But the world of
> > embedded devices becomes more and more complex. Different
> vendors are
> > making their own components, and device manifacturers (like
> Nokia) put
> > those components together almost as if they were Lego
> bricks. I.e., it
> > becomes much harder to control that everyone is doing the
> same at the
> > same time because the components are black-boxed. Flexibility is
> > needed. And versioning is an important part of successful
> flexibility.
> > Take USB. You plug-in a USB-1 device in an USB-2 port, and it works.
> > TCF should be the same, IMHO.
> >
> > Best regards,
> > Thomas Emil Hansen
> > Solution Architect
> > Nokia R&D, Development Solutions
> > Mobile phone: +45 20 91 26 44
> > Email: thomas.e.hansen@xxxxxxxxx
> > Nokia Denmark
> > Frederikskaj & Sydhavnsgade 15-19
> > DK-1790 Copenhagen
> > Denmark
> >
> >
> >
> > -----Original Message-----
> > From: ext Burton, Felix [mailto:Felix.Burton@xxxxxxxxxxxxx]
> > Sent: 20. marts 2009 00:50
> > To: Hansen Thomas.E (Nokia-D/Copenhagen)
> > Cc: Oberhuber, Martin; dsdp-tcf-dev@xxxxxxxxxxx
> > Subject: RE: TCF communication protocol versioning
> >
> > Hi Thomas,
> >
> > As Martin noted, I do have an action to add version
> information in the
> > documents. However, reading your email I get the
> impression that your
> > question is more in regards version information at run-time
> than in the
> > documents. For TCF there are two types of run-time versioning:
> >
> > 1. Versioning of protocol and service interfaces, and 2.
> Versioning of
> > the implementation of a client or value-add
> >
> > Regarding #1: The strategy is to change the name of a
> service whenever
> > a incompatible change is made, so for example if a backward
> > incompatible change is needed on a service named
> "PhoneBook" is needed
> > its name would change to "PhoneBook2". In order to allow
> older clients
> > that still relies on the "PhoneBook" service to continue to
> function,
> > the service implementation could implement both "PhoneBook" and
> > "PhoneBook2". In most cases, the underlying implementation
> of the two
> > interfaces would probably be shared, so this would not have a
> > significant footprint impact. An alternative way of achieving
> > backwards compatibility is to have a value-add that
> translates between
> > the old and the new service.
> >
> > For changes to the channel protocol or the marshaling of messages we
> > would like all changes to be negotiated between the peers such that
> > changes will only take effect of both sides agree to the
> change. The
> > plan is to use special service names to indicate which new
> features are
> > supported.
> >
> > Regarding #2: We have discussed adding a command that returns
> > information properties about the implementation of a peer. This
> > information could include information about the version, vendor and
> > other things. This command has not been implemented or documented
> > since we have not seen a need for it yet.
> >
> > Hoppe this helps,
> > Felix
> >
> > > -----Original Message-----
> > > From: Oberhuber, Martin
> > > Sent: Thursday, March 19, 2009 5:54 AM
> > > To: Thomas Emil Hansen; Burton, Felix; dsdp-tcf-dev@xxxxxxxxxxx
> > > Subject: Re: TCF communication protocol versioning
> > >
> > > Hi Thomas,
> > >
> > > there is a plan to version the TCF Protocol Specification
> in a fine
> > > granular way. Felix Burton has the action item to do that:
> > >
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=269352
> > >
> > > I just created the bug for tracking the effort, but we
> did discuss it
> > > on the TCF Round Table meeting recently:
> > >
> > >
> > http://wiki.eclipse.org/DSDP/TCF/Meetings/March_12_2009_Round_Table
> > >
> > > Cheers,
> > > --
> > > Martin Oberhuber, Senior Member of Technical Staff, Wind
> River Target
> > > Management Project Lead, DSDP PMC Member
> > > http://www.eclipse.org/dsdp/tm
> > >
> > >
> > >
> > >
> > > Thomas Emil Hansen wrote:
> > > > What is the version of the TCF communication protocol
> specified in
> > > >
> http://dsdp.eclipse.org/dsdp/tm/tcf/docs/TCF%20Specification.html ?
> > > >
> > > > Is there a way, or planned a way, to have versioning as
> part of the
> > > > protocol itself? For example, it could be possible for
> the PC side
> > to
> > > > request the target for the version used.
> > > >
> > > > Or the target could be allowed to use various versions of the
> > > procotol
> > > > in parallel, and the PC side would know, for example by
> looking at
> > > the
> > > > message header, which version the message belongs to. This would
> > make
> > > > really good sense if different parts of the target is delievered
> > from
> > > > different vendors, each implementing different versions of the
> > > protocol
> > > > (you can't expect everyone to upgrade at the same time).
> > > >
>
