OpenBCM V1.07b6_bn2 (Linux)

Packet Radio Mailbox

DBO841

[Box Weng]

 Login: GAST





  
HF1BKM > INFO     18.08.14 15:36l 31 Lines 1446 Bytes #999 (999) @ DEU
BID : IO8NB1BKM_0D
Read: GAST
Subj: Ergaenzung zu ATD233
Path: DBO841<DBO763<AS1BOX<NB1BKM
Sent: 140818/0905z @:NB1BKM.#BAY.DEU.BCMNET [OBB JN57XV] obcm1.07b6_bn2 LT:999
From: HF1BKM @ NB1BKM.#BAY.DEU.BCMNET (Franz)
To:   INFO @ DEU
X-Info: Sent with login password

Ergaenzung zu Alkans Info

¯ wer DIG233 Besuchen möchte kann das über folgende Nodes machen
¯ CB0HAL CB0DLN-8 CB0ESN CB0NET DB0DIB CB0VER DIG396 DND946 DHH500

Wer die vom Alkan benannten Node besuchen möcht, kann dazu wie bisher ganz
normal in seinem Heimatnode direkt die benannten Nodecalls connecten, weil
zumindest der BN1BAY als Flexgate funtkoniert und zum DIG233 selbst einen Link
unterhält.

Insgesamt ist aber Alkans Methode ein Beitrag, die Anzahl der
Routinglinkleichen zu reduzieren.

Denn nach wie vor haben zu viele Sysop ihre Node nicht der deutlich zu dichten
Vernetzung im CB-PR-Nodenetz angepasst parametriert, sodass sich Fehler der
TNN in Verbindung mit XNet gerade bei Routingzielen, wie etwa direkt zu einem
Sysop - was grundsätzlich nur einem übersteigerten EGO geschuldet ist - der
nur zeitweise an seinem Terminal qrv ist und daher im Routing bei Abwesenheit
auch abgemeldet werden sollte, eben aufgrund der mit jeder zusätzlichen
Verlinkung mit anderen Linkpartnern über die dadurch potenzierte Anzahl der
möglichen Linkwege zu zeitlich verzögerten Echos der Routingmeldungen führt
und Routinglinkschleifen, die beim Ausfall eines solchen Zieles nicht mehr
aufgelöst werden können, führt.

Beispiel: DCT645. Der wird im restlichen Netz immer noch als erreichbar
gemeldet, obwohl er seit Stunden offline ist.

73 vom Franz


Lese vorherige Mail | Lese naechste Mail


 08.01.2026 00:22:30lZurueck Nach oben