(I keep telling myself that I should sit on my hands and stay out of
the fray, but a couple of comments warranted something in return...)
X.25 can blow the doors off of PPP when it comes to real
interoperation and effective reliability.
I won't argue with that; however...
I might argue with that. After 13 years of experience and three
rounds of standards (1980, 1984, and 1988), X.25 is starting to
mature. But there are still buggy commercial X.25s out there, and
even some carriers with buggy implementations. And as Jim pointed
out, X.25 is still confused as to its purpose and which layer it
If all you want is a freebie hack that might work most of the
time, by all means use PPP.
There are good commercial implementations of ppp out there,
Morningstar for example (and given the unnecessary complexity of
ppp, these people have my respect).
Thanks, but we've found X.25 to be much more complex than PPP, and
much harder to support in the field. The biggest support problem is
X.25's unimaginable variety of options, and its primitive negotiation
methods. It can be described in a sort of finite state machine, but
such a FSM must be inferred from the standards. And that inferred FSM
is so complex, with so many special cases, as to be nearly
Thus the wide variety of X.25 conformance testers. In order to be
allowed to connect with a given nation's telephone system, an X.25
implementation must pass its own particular tests. *All* those test
suites have serious bugs, so *all* X.25 implementations must have many
behaviors: one that comes as close as possible to meeting the CCITT
specs, and another for each network to which it wishes to connect - to
accomodate the bugs in that network's preferred test suite.
PPP may have complexity you consider unnecessary, but it's far simpler
than X.25, and far easier to support. Just as one crude measure:
% cat /mst/obj/x25/*.[chysl] | wc
75974 272360 2036095
5.0u 4.3s 0:20 46% 0+192k 0+0io 365pf+0w
% cat /mst/obj/ppp/*.[chysl] | wc
26545 83864 616641
There has been talk from time to time of making a PPP conformance
tester, but in actual practice it really hasn't been very necessary so
far. PPP implementors test against each other at periodic bakeoffs,
where everyone benefits.
(In fairness, PPP has come a long way; but they did push through
to Internet Standard a version that didn't even have a properly
working state machine;
PPP has gone through three revisions (RFCs 1134, 1171, and 1331), and
now has a fairly mature state machine. Most users just plug it in and
it just runs.
X.25 has gone through three revisions (1980, 1984, and 1988) and still
lacks any explicit state machine for negotiating configuration
options. Each of its many options must still be hand-configured for
and they still don't understand some things about datalink that
have been known and implemented in (e.g.) X.25 for 2 decades.
PPP _may_ still get somewhere; but I wouldn't use it yet.)
The PPP community hasn't solved all the problems, but it's learning
fast. It has indeed gotten somewhere, and lots of people are using it
to solve their real-world problems.
And as you yourself pointed out, there are poor commercial
implementations of x.25.
There are poor commercial implementations of everything, including
both X.25 and PPP. Hopefully, they're all maturing, so that customers
have a good field of choices to best match the demands of their own
Bob Sutterfield, Morning Star Technologies +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221 +1 800 558 7827