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.