FidoNews · Vol 2, No 18 · 17 June 1985
FIDONEWS -- 17 Jun 85 00:00:20 Page 1
Volume 2, Number 18 17 June 1985
+----------------------------------------------------------+
| _ |
| / \ |
| - FidoNews - /|oo \ |
| (_| /_) |
| Fido and FidoNet _`@/_ \ _ |
| Users Group | | \ \\ |
| Newsletter | (*) | \ )) |
| ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+----------------------------------------------------------+
Publisher: Fido 107/375
Chief Procrastinator: Thom Henderson
Fidonews is published weekly by SEAboard, Fido 107/375. You
are encouraged to submit articles for publication in
Fidonews. Article submission standards are contained in the
file FIDONEWS.DOC, available from Fido 107/375.
Disclaimer or don't-blame-us:
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them;
everything here is subject to debate. We publish EVERYTHING
received.
In Defense of Copy Protection
No, I haven't lost my marbles. And no, I don't like copy
protection either. But there IS more than one side to this
issue, and I'd just like to point out a few facts for the
other side.
The major problem in this industry today is software piracy.
It's been estimated that over half the copies of 1-2-3 in
use by major corporations are pirate copies. Wordstar does
even worse than that. One of my sources tells me of a major
international corporation where almost every PC is equipped
with a large assortment of pirated software, and the people
using it see nothing wrong.
I've lost count of how many times I've heard people complain
that the software houses should "get rid of expensive copy
protection and just price the stuff reasonably." I'm told
that Lotus charges far too much for 1-2-3, and that if they
only asked (figure varies, generally under a hundred bucks)
then nobody would pirate it and they'd make more money.
Bull chips. They could sell it for ten bucks a pop, and
FIDONEWS -- 17 Jun 85 00:00:22 Page 2
people would STILL pirate it. As for the price being
unreasonable, I have news for you. The retail price of
1-2-3 would just about get you my services for ONE DAY, so
think for a minute how much 1-2-3 would cost if you tried to
get someone to write it for you.
The upshot is that when a company does an honest piece of
work and produces a quality piece of software, they deserve
to make some bucks on it.
FIDONEWS -- 17 Jun 85 00:00:22 Page 3
============================================================
NEWS
============================================================
In view of the expansion of Fido, I would like to propose an
idea for reduced-cost mail, involving low overhead on the
part of each local board, and a LARGE overhead on the part
of the network manager.
Fido COULD send mail from local dialing area to local
dialing area, but to do this would involve creating a graph
containing all Fidos, each graph containing COMPLETE routing
instructions for point-to-point transfer. At each receiving
station, (pardon my LISP) take CAR(ROUTE-LIST) as the next
node to transmit to, and send CDR(ROUTE-LIST) as the New
ROUTE-LIST. Upon arrival at the desired point, CAR(ROUTE-
LIST)=NIL, and the message has arrived at its final
destination. The file sent could easily be small relative
to ROUTE-LIST, and each Fido would have to store (#NODES)^2
maximum ATOMS - this is a HUGE amount of disk overhead.
The idea I would like to suggest would be that each FIDO
store a route map for its LOCAL hub only, with designated
Fido GATEWAYS to the next hub in the direction of travel.
Each GATEWAY would have LOCAL numbers leading into a new
hub, would check the final-destination address, and pass it
to the next hub. The incoming gateway would then route to
an appropriate gateway in its hub, or to its final
destination if in the current hub.
The biggest problem in this is the construction of the map -
and what to do in the event of a GATEWAY FAILURE (i.e. the
gateway is down or otherwise unable to pass messages).
Adaptive routing would be nice, except that this involves a
large communications overhead (each active node must
periodically pass the list of LOCAL Fidos that it can
actually contact to each GATEWAY in its hub.) My guess is
that this would entail an additional 15-20 minutes per day
(or mail period) in receiving and transmitting local connect
information. If adaptive routing is not made automatic, one
node would have to determine the map of local nodes and
gateways, and go from there. Inter-hub linkages should be
made redundant (i.e. if hub 1 wants to talk to hub 2, there
should be more than one gateway to hub 2, if at all
possible.)
The message traffic bottleneck would come at the GATEWAYS -
it would be essential that (1) the gateway have sufficient
hard disk storage to hold all incoming or outgoing mail for
the HUB!!! and (2) the gateway have the capability of
reporting to the net the failure of another gateway, so that
alternative routing can be generated. The mathematics
involved in this part of the problem would be (1) topology
and (2) graph theory. Andrew Tannenbaum's "Computer
Networks" (Addison-Wesley, 1981) discusses these topics in
relation to mainframe point-to-point networks (the examples
are ARPANet and IBM's SNA), and discuss the possible
solutions.
FIDONEWS -- 17 Jun 85 00:00:25 Page 4
I currently have a program which is used to solve this type
of problem in a generic sense - it is a modification of DR's
NETWORK2.PLI program. In order to use this program, it is
necessary to construct an exhaustive list of the local
dialing area overlap relative to FIDO nodes. This program
as presently written is memory bound - I do not think that
the mapping for a 1000 node system could be stored in less
than 384K on a PC under PC-DOS 2.1 (we run the program on
the CompuPro here in house to solve LAN gateway problems.)
Under Fido version 10i, the point-to-point could only be
handled within a local hub - there are two main reasons that
it would be difficult to use for other purposes:
(1) There is no provision in the FidoMail to place more
than a total of two destinations for a file - the first is a
transmit-to address for an incoming gateway, the second
being the final distribution address. This would make it
possible to make a two-jump transfer - transmit to an
incoming during National Mail, and then redistribute during
a local mail period. This would be practical for messages
between, say, New Haven and Bridgeport, with an incoming
station in Milford.
(2) The amount of time it would take to make a long
distance trip would be prohibitive. Suppose that using
local-to-local jumps, you could have a message make three
jumps per day - about 50-70 miles. It would take about 40
days to get to a destination in California!!! Also,
discontinuities would exist between many locations - those
locations would be unreachable under the FREEMAIL concept.
In the event of a gateway failure, either a new FREEMAIL
route would be needed (adaptive routing), or the mail would
be further delayed - possibly forever if the gateway remains
down.
Any suggestions or comments should be sent to:
Ed Rauh
FIDO 215 (BCP Technology)
(203) 777-7763
(300/1200 baud, 8-1-N or 7-1-E)
Bulldog Computer
1334 Chapel Street
New Haven, CT 06511
Incidentally, we have several unique ports of Fido, one to
our Turbo PC (runs at 7 MHz) under a modified CPC-DOS 3.2,
and another under MS-PRO (MS-DOS 2.1 for the CompuPro from
Computer House.)
FIDONEWS -- 17 Jun 85 00:00:27 Page 5
============================================================
NOTICES
============================================================
* * * WARNING * * * WARNING * * * WARNING * * * WARNING * * *
PIRACY WARNING
Several game programs have been making the rounds, billed as
public domain versions of Atari games. This includes (but
is not limited to) the following games:
STARGATE
ROBOTRON
MOONBUGS
ZAXXON
If you have any of these games on your board, please remove
them as soon as possible.
------------------------------------------------------------
*** Calendar of Events ***
18 Jun 85 RSVP deadline for the Next Occasional MetroNet
Sysop Meeting.
22 Jun 85 The Next Occasional MetroNet Sysop Meeting.
23 Jun 85 Submissions deadline for next issue of Fidonews.
If you have any event you want listed in this calendar,
please send a note to node 107/375.
Download original FidoNews · Volume 2 (1985) · ← Previous · Next →