On Fri, 31 Jan 1997, Mike Bilow wrote:
> TD> I'm not sure that the bad mess would be all that bad. What
> TD> you are describing as a bad mess is pretty much how X.25
> TD> works. Because LAPB has no way of knowing the nature of the
> TD> network data it just shunts the data off as fast as it is
> TD> able. It's just an implementation issue to prioritise
> TD> network traffic if that is a concern to you.
>
> Sure, but X.25 is an inherently low-bandwidth protocol. It was originally
> designed to operate on 2400 bps links and slower. At these speeds, the
> difference is qualitative, not merely quantitative. What I mean is that you
> could use X.25 for connecting dumb terminals or remote job entry machines, but
> no one would want to use it for web browsing or digitized voice. Also,
> connectionless network protocols such as IP do not work very well across X.25,
> so there is a significant loss of generality.
I would dispute the assertion that X.25 is an "inherently low-bandwidth
protocol", I have the 1992 specification of it here, and both the link
layer and packet layer both support extended sequence numbers (modulo 127)
and of course the maximum permitted data segment size for X.25 is vast. I
would contend that an X.25 system running at full steam with extended
sequence numbers and large data payload size could give TCP/IP a run for
its money, and maybe even beat it for throughput, for a given link.
Of course I am a little biased since I am writing the "real" X.25
implementation for Linux at the moment. It makes a change to work on a
link layer where there aren't problems with addresses and I don't have to
shoehorn weird exceptions into it.
> -- Mike, N1BEE
Jonathan
-- +----------------------------------+---------------------------------------+ | e-mail: jezeca@teaser.net | Telephone: +44 (0) 973 695261 | +----------------------------------+---------------------------------------+ | Author of Linux kernel AX.25, NET/ROM and Rose. | +--------------------------------------------------------------------------+