At 08:05 AM 1/15/99 +0000, Mike Bilow wrote:
>
>
>Nate Bargmann wrote in a message to Mike Bilow:
>
[snip... interesting and valid arguement]
>
>Second, node functionality stagnated. The basic BBS model for packet activity
>was reasonable in the days when the idea was to share a Xerox 820 CP/M
>computer, and it was a requirement that ordinary users be able to work from
>dumb terminals rather than computers. Even very substantial technical
>achievements, such as the F6FBB software, are coerced into this model. The
>worst example is the DX Cluster network, which was without question the most
>inefficient possible application for the BBS model. I don't mean to criticize
>the demand for DX Cluster functionality, but that demand should have been
>satisfied with a more intelligent and efficient architecture making use of
both
>simple techniques that have been known for decades, such as NAK-only datagram
>protocols, and newer developmental techniques, such as multicasting.
>
>Third, network functionality stagnated. By the time netrom was designed, it
>was well understood that much of its underlying technology was a bad idea,
>specifically directed-vector routing and virtual-circuit connectivity. As a
>result, netrom became grossly unsuited to exactly the types of advanced
>protocols which were demanded by DX Cluster and other applications, such as
>multicasting. Furthermore, netrom was coerced into an EPROM and 8-bit CPU,
>repeating the same mistakes of AX.25, rather than being computer-based and
>expandable. Could one ever hope to move video, for example, over netrom?
>
>Fourth, the physical layer stagnated. The original packet protocols were
>chosen for no better reason than that someone got a good deal on a bunch of
>surplus Bell 202 modems. As a result, we ended up stuck with a physical layer
>that is essentially indistinguishable from 1940s RTTY, except for a wider
>shift. Sure, we use synchronous timing, but that just makes it worse. The
>failure to use even basic forward error correction has proven to have been
>probably the greatest single mistake in packet. Of course, there's that 8-bit
>CPU issue coming back again.
>
>Fifth, and probably most damning, is that all of these engineering issues,
>which were really just mistakes motivated either by shortsightedness or a
>desire to get something rather than nothing, evolved into political issues.
>Netrom enthusiasts, not understanding that they were being held hostage by the
>inherent defects of their protocol, began forming guilds and kicking out
anyone
>who questioned the wisdom of their settings. DX Cluster enthusiasts, not
>understanding that their protocol made them a bull in a china shop, just kept
>right on knocking over the display cases and smashing the crystal. And BBS
>sysops continued right on serving a user base that no longer exists.
>
[snip... more interesting and valid arguement]
Please look at what we're trying to do to move the DXcluster on from the
stone age.
All new implementation, DXspider, written in PERL to run on Linux, supports
TCP/IP and AX.25 connections. Currently discussing and planning UDP
and multicast protocols to make exactly the major steps in improvements
discussed/required/needed/overdue above.
DXspider is an Open Source model project - the idea taken directly from
the highly successful linux kernel project.
Information and current versions of DXspider are available on the web at:
www.dxcluster.org
Please join in and help/contribute!
Regards
Mike Tubby G8TIC
