Michael J. Tubby B.Sc. G8TIC wrote in a message to Mike Bilow:
MB> The worst example is the DX Cluster network, which was without
MB> question the most inefficient possible application for the BBS
MB> model. I don't mean to criticize the demand for DX Cluster
MB> functionality, but that demand should have been satisfied with
MB> a more intelligent and efficient architecture making use of
MB> both simple techniques that have been known for decades, such
MB> as NAK-only datagram protocols, and newer developmental
MB> techniques, such as multicasting.
* * *
MJTBSG> Please look at what we're trying to do to move the DXcluster
MJTBSG> on from the stone age.
MJTBSG> All new implementation, DXspider, written in PERL to run on
MJTBSG> Linux, supports TCP/IP and AX.25 connections. Currently
MJTBSG> discussing and planning UDP and multicast protocols to make
MJTBSG> exactly the major steps in improvements
MJTBSG> discussed/required/needed/overdue above.
MJTBSG> DXspider is an Open Source model project - the idea taken
MJTBSG> directly from the highly successful linux kernel project.
Well, let me emphasize that, as I said above, I don't mean to criticize fthe
demand for DX Cluster operations, and it turns out to be one of the more
technically challenging spheres within packet. That said, I personally do not
do enough DXing to have any reasonable idea of what is really needed or wanted.
I am very glad to see that there is an effort made to fix it and improve it,
and I think open source is definitely wise in this situation.
The design issues in DX Cluster are very complicated, especially because, as I
understand the system, there are two fundamentally different scopes of
operation. There is first a "front end" which is what the users see, and there
is also a "back end" which is what the DX Cluster nodes use to talk among
themselves. DX spot announcements, for example, are short messages that must
be relayed very quickly throughout a network of many Cluster nodes so that they
can be disseminated to the list of users subscribed for that bit of
information. Making sure that such a system works quickly and efficiently is
bad enough, but making sure that it does not avalanche down in a storm of data
is a significant technical challenge on the edge of current techniques.
MJTBSG> Information and current versions of DXspider are available
MJTBSG> on the web at:
MJTBSG> www.dxcluster.org
MJTBSG> Please join in and help/contribute!
I appreciate the suggestion. As I said, if I knew enough about DXing, I would
probably be more willing to get involved. I am curious about one thing you
mentioned, however: why did you choose to implement this in Perl?
-- Mike