Re: ANTS Evolution and Interoperation

[Timothy Stack <stack@cs.utah.edu>]

> 	In ANTS-2.0.0, the "ANTS Version" field in the Dante Join
> packet was 2.4, and the MID value was something-or-other.  In the
> current CVS (ANTS-2.0.1+?), the ANTS Version field remains at 2.4, but
> the MID value has changed to something-or-other-else.  When I coded my
> ANTS ABone monitoring software, I assumed that that the MID value
> would remain constant for a given value of the ANTS Version field.  I
> was wrong. :-)

I don't know if we've properly updated the version number in the
repository so this might be a minor issue.

On a similar note though, does protocol take versioning into account in
the first place?  If its working on the MID/PID produced from the code it
will always be changing and hence only one version at a time will work
together...  I'm still a little ignorant of Dante, but I'll look into this
in a bit.

> 	A flag day was needed in my ANTS topology and monitoring
> software, and I need to change the approach my monitoring software
> uses to identify which version of ANTS it's monitoring.  This could be
> tedious if there are lots of different releases of ANTS-2.0 (2.0.0,
> 2.0.1, 2.0.2, 2.0.3, ...), each with a different MID, and we end up
> running several of them concurrently in the ABone (because once
> someone starts using a particular version for their application, they
> might not want to put in the effort to keep up with new releases, but
> other developers might want to start with the latest release, etc.)

Hmm, I had never really thought about this...  

So, the problem is that ANTS treats even minor changes as a completely
different protocol.  But this sucks for newer versions of protocols
because there is no way to tell that they really do have something in
common.  And, without a way to detect this commonality things don't work
(monitors, Dante).

Bah, i don't know what to tell ya...  Modifying the monitor to work with
it or running multiple monitors will probably work.

> 	I think that this is an expectations management problem as
> much as a technical problem.  Which of my expectations should I manage
> differently, please?

You might just have to upgrade every node in lock step for now...

> 					Craig Milo Rogers

tim stack