Riley Williams wrote:
> Partly out of curiosity, and partly in connection with a project I
> might be working on shortly, but can anybody advise whether the
> current (2.2.0-preX) implementation of AX.25 implements either of the
> SABME or SREJ frame types, and if so, whether there's any limitations
> thereon?
You're referring to AX25 V2.2?
Whe had a rather long discussion last year in Darmstadt. Several
AX.25 implementers (FlexNet, NordLink, Matthias Welwarsky,
the current Linux AX.25 hacker) were there. We agreed that this new
spec is completely bogus.
These are some of the more severe reasons:
SABME/SREJ is an attempt to implement selective repeat
(instead of go back N). We (in central europe) already
use a selective repeat scheme called "frame collector"
for almost 10 years now. It uses existing protocol elements
(RR P/F), is backward compatible, and does not incur much
complexity.
TAPR OTOH chose to implement a scheme that is _extremely_
complicated, and even has more drawbacks than the simple
frame collector scheme.
The reduction of digipeater fields to 4 is just ridiculous.
It kills FlexNet, but doesn't give any advantage (_still_
variable length header).
The Spec mandates things that are not needed to be specified
for interoperability, and it makes a complete layering mess.
Just look at the timer chapter.
I can't see how anyone would be able to implement this mess
in a TNC with less than 1Meg RAM and 1Meg ROM.
The authors were SDL guys. I've already been bitten by
SDL enthusiasts basing design decisions on SDL's features
and thereby killing performance.
The SDL generated C code is unusable if you want performance
(we _want_ performance, 100kBps++ link transceivers
already exist!!)
The way TAPR did the design process (essentially secretly,
no one of the major AX.25 implementors, such as
Nordlink or Flexnet) new anything about it or was even
asked what they think of it.
If you want a public standard followed by all major
implementors, make the standard setting process open!!
Tom
