Sun thumbs its nose at a 30 year-old goal (including its own)
Charles T. Smith
beginning. But for X.25, Sun blithely pushes its NLI interface - which is
basically hard-coded X.25. It shares no abstractions with any other API
and is not compatible with any of the facilities that support all other
protocols as a group. Plus, it is complicated to use (despite that Sun
uses happy tones to market it).
Somebody at Sun ought to take responsibility.
Andrew Gabriel
X.25 doesn't look enough like many modern protocols to survive
very much abstraction, unless you are restricting yourself to
a small subset, which most applications running over it don't.
X.29 which you referred to in an earlier posting uses all those
features of X.25 which nowadays look rather strange in a protocol.
An X.25 connection effectively gives you three data streams in
each direction, two of which support infinate length records
but can't be used together (unqualified and qualified data),
and the third which supports only short length records with no
flow control (interrupt data), not to mention resets which
discard all data and take the connection back to its initial
state. Some of these features have appeared in SCTP, but they
just don't exist in the classical protocols used on UNIX.
One pitfall of NLI is making the packet and window sizes visible
to the programmer, and I've seen programmers drive that wrongly
and wonder why their application doesn't work (or crawls at a
snail's pace). So yes, you do have to know some of the details
of the X.25 protocol in order to use NLI.
NLI is not of Sun's making -- it is a vendor standard for X.25
support which virtually all UNIX X.25 implementations used.
Most of the NLI implementations were derived from the original
Spider implementation of the 1980's. (Sun's did also originally,
but they rewrote their own implementation at some point,
possibly at SunLink 8.)
Remember, X.25 predates ISO protocols. Attempts to draw it in
the OSI 7-layer model are retrospective refitting, and it
doesn't fit too well, although sucessive enhancements to X.25
level 3 over the years was an attempt to make it fit enough
of OSI layer 3 so that ISO layer 4 protocols could use it
(NSAP addressing, longer interrupt packets).
X.25 is a protocol which is at the end of its life. It will
continue to exist for years, but usage will decline and no one
is producing any new drivers for it nowadays. Otherwise it
would be worth taking a look at improved APIs, particularly in
the light of SCTP which has a number of similar features.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Chris Ridd
Gabriel) said:
> X.25 is a protocol which is at the end of its life. It will
> continue to exist for years, but usage will decline and no one
> is producing any new drivers for it nowadays. Otherwise it
> would be worth taking a look at improved APIs, particularly in
> the light of SCTP which has a number of similar features.
There's at least one X.25 gateway box that I'm aware of which you can
connect to over TCP/IP (using RFC 1006), which at least gives you other
options than using Sun's X.25.
Cheers,
Chris
Tim Bradshaw
> Protocol independence has been the goal of network programming since the
> beginning. But for X.25, Sun blithely pushes its NLI interface - which is
> basically hard-coded X.25. It shares no abstractions with any other API
> and is not compatible with any of the facilities that support all other
> protocols as a group. Plus, it is complicated to use (despite that Sun
> uses happy tones to market it).
My guess is that the X.25 market is small and shrinking rapidly and
there's just no possible commercial motivation to spend money
modernising stuff at this point (especially as they would still have
to maintain all the old APIs if they have any existing users at all,
which they probably do)
--tim
Charles T. Smith
I wouldn't mind if the implementation used non-abstract constructs to
access features of x.25 that aren't in that "small subset" (only because
it is truly EndOfLife) - but sockets and Sun already offer x.25 facilities
that are compatible with protocol independence - Sun is throwing the baby
out with the bathwater.
I mean, I guess there is grudging support for x.25 sockets and tli, but I
posed the same question to Sun that I essentially posed here - why does
Sun recommend NLI - and the answer I got was paragraphs that said because
Sun recommends NLI.
I suppose I could accept that NLI was the coup-de-grace for X.25 - if Sun
would just publish a white paper that would discuss how it compared
to their socket and tli implementations.
and...@cucumber.demon.co.uk
RFC1006 is a mapping of ISO transport service over TCP. That won't
help the original poster as X.29 is not an ISO protocol and doesn't
run over ISO transport service. Nearer to the mark would be a Telnet
to X.29 gateway, if such things still exist. X.29 fulfills a similar
role to
Telnet -- it's the protocol used by a PAD to wrap up a terminal
session
for carrying directly over X.25 (in conjunction with X.3 which is the
equivalent of the telnet options values, and X.28 which is a defined
user
interface to a PAD).
(10 to 25 years ago, I did implementations of all the above:-)
--
Andrew