Date: Mon, 9 Jan 89 23:33:28 MET Message-Id: <301@pe1chl.ampr> From: rob@pe1chl.ampr (R.E. Janssen (PE1CHL)) Reply-To: rob@pe1chl To: roel@pe1jlj, max@pe1lgt, joop@pe1dna, geertjan@pe1hzg Subject: NET/ROM Message gedumpt in de PANET mailboxen, helaas hebben we zlf nog geen "news" faciliteit... Beste TCP/IP'ers Zoals we allemaal kunnen zien zijn er de laatste tijd erg veel nieuwe stations met het KA9Q NET programma bijgekomen. Allen welkom in de gebruikersgroep, en veel succes met het leren van het gebruik van het programma (sorry, dit niet altijd even eenvoudig. de documentatie is slecht toegankelijk. verbetering is echter op komst, nog even geduld...) Het toenemend aantal gebruikers blijkt te leiden tot een aantal kleine probleempjes: - De HOSTS.NET file wisselt snel van inhoud, het wordt lastig hem uptodate te houden. Gelukkig verricht PA0GRI de inspanning om de zaak centraal te administreren, zodat het allemaal prima blijft lopen. De volgende versie van NET zal ook het verspreidingsprobleem van deze file aanpakken. - De routering binnen NET is een zwak punt, we zijn afhankelijk van min-of-meer altijd aanwezige stations om grotere afstanden te overbruggen, en het opstellen van een fatsoenlijke route tabel is niet eenvoudig. - De automatische routerings faciliteiten zoals geboden door NET/ROM lijken een goede oplossing, maar de capaciteit is beperkt. Dit laatste punt is het onderwerp van dit verhaal. Nu er zoveel stations QRV zijn ontstaan er lange node-lijsten ten behoeve van NET/ROM, deze worden immers automatisch gevuld aan de hand van ontvangen broadcast berichten. Voor de NET gebruikers zelf is dat geen probleem, de capaciteit van NET is nog niet bereikt, zeker niet bij de 68000 implementaties. Het bestaande NET/ROM netwerk werkt echter met Z80-bestuurde TNC's die slechts over 32K RAM beschikken, en om deze reden is het aantal nodes wat deze NET/ROM's kunnen bevatten beperkt. Nu onstaat momenteel de situatie dat de TCP/IP gebruikers de schaarse plaats in het bestaande NET/ROM netwerk volledig bezetten, waardoor de oorspronkelijke gebruikers van dit netwerk ernstig in de verdrukking dreigen te geraken! Om te voorkomen dat de Sysops van dit NET/ROM netwerk maatregelen zullen treffen die ons gebruik zullen belemmeren, denk ik dat we vrijwillig zelf een oplossing zullen moeten vinden. Dit zal moeten bestaan uit een beperking van het aantal actieve NET/ROM stations, aangezien de mogelijkheden om de verspreiding van de node informatie tegen te gaan nog zeer beperkt zijn. Welke stations zouden nu het beste hun NET/ROM kunnen uitschakelen? 1. Stations die niet continu QRV zijn, kunnen beter de NET/ROM broadcasts niet uitzenden. De tijd dat een afgeschakeld station nog in de diverse tabellen blijft staan is minstens 6 uur, en meestal nog langer. Dit betekent dat een station dat iedere dag slechts enkele uren QRV is nogal wat verkeerde routes kan veroorzaken cq. achterlaten. 2. Stations die niet over een goede antenne beschikken en daardoor slechts een beperkt bereik hebben functioneren niet zo goed als node in het NET/ROM netwerk. Dit is ook het geval als het uitgangsvermogen onevenredig groot is t.o.v. de ontvanger gevoeligheid, of omgekeerd. Wel nuttig als NET/ROM node zijn: 1. Stations met een goede locatie, die in principe 24 uur per dag QRV zijn. 2. Stations die een bepaalde faciliteit kunnen bieden, zoals een gateway tussen verschillende frekwenties. Ook deze moeten dan in principe wel 24 uur per dag QRV zijn. De andere TCP/IP stations in de omgeving kunnen deze NET/ROM stations gebruiken om verkeer naar verafgelegen stations te routeren. Dit gebeurt door in de file ROUTES.NET een regel op te nemen van de vorm: route add via Uiteraard moet het NET/ROM station ook de juiste route tabel hebben om het verkeer daadwerkelijk via NET/ROM te laten lopen, dit is de voor NET/ROM gebruikelijke constructie. Hoe kan men de NET/ROM uitschakelen? Als men geheel geen gebruik wenst te maken van de NET/ROM faciliteit kan de zaak het beste helemaal worden uitgeschakeld. Dit kan het gemakkelijkst door in de AUTOEXEC.NET file de "netrom interface..." commando's onwerkzaam te maken door er een # voor te plaatsen. Dus: #netrom interface 144 "#TCPIP" 192 #netrom interface 430 "#TCPIP" 192 Het is dan niet meer mogelijk NET/ROM te gebruiken, en er wordt ook geen geheugen gebruikt voor het opslaan van nodelijsten. Een minder drastische oplossing is het niet meer uitzenden van broadcast berichten waarin de eigen call als NET/ROM wordt geadverteerd. Dit kan eenvoudig gebeuren door in CONFIG.NET de regel "netrom nodetimer..." onwerkzaam te maken: #netrom nodetimer 3600 In dit geval wordt wel de locale nodetabel up-to-date gehouden zodat het wel mogelijk blijft via NET/ROM te werken. Men kan andere stations die in de nodelijst staan via NET/ROM bereiken, en zodra dit gedaan wordt dan wordt automatisch een retour pad opgenomen in de diverse node tabellen "onderweg". Wil men op een bepaald moment de NET/ROM call verspreiden dan kan dit eenvoudig met "netrom bcnodes " of door het "netrom nodetimer 3600" commando zelf in te typen. Voor wie toch met NET/ROM wil werken, is het aan te raden om met behulp van de "netrom nodefilter..." commando's een filtering op te zetten die voorkomt dat allerlei routes worden uitgezonden die zeer marginaal van kwaliteit zijn. Dit bevordert de kwaliteit van de verbindingen enorm! Het beste is, de "netrom nodefilter mode accept" te kiezen, en dan in de AUTOEXEC.NET file alleen de nodes op te nemen waar van men weet dat er een goede verbinding mee is, d.m.v. "netrom nodefilter add ". Het onstaan van allerlei onmogelijke routes, vooral bij wisselende condities, wordt hiermee voorkomen. Ik hoop dat het bovenstaande begrijpelijk is, dat het niet op een negatieve manier wordt uitgelegd, en dat we de NET/ROM Sysops te vriend zullen houden door een verantwoord gebruik van de NET/ROM faciliteiten in NET, ook bij een groot aantal enthousiaste gebruikers. 73, Rob@PE1CHL [44.137.40.1]