🚀 go-pugleaf

In article <JOCHEN.92Aug12192756@busybit.mrz.sub.org>, Jochen Fahrner writes:

> Was mich aber dennoch wundert: Wieso reagiert das uucp-g Protokoll so
> empfindlich auf verlorene Zeichen ?

	Mit einem verlorenen Zeichen verliert das g-Protokoll immer
mindestens zwei Pakete (fast, bei Windowsize 1 wohl nicht unbedingt,
aber... :) ): das Paket, zu dem das verlorene Zeichen gehoerte -
logisch - und das nachfolgende Pakete, denn dessen Header wird nicht
erkannt.  Der Anfang des Headers wird als Ende des ersten Pakets
eingelesen, dem ja noch Zeichen fehlen.  Erst das dritte Paket kann
wieder erkannt werden, weil der uucico nach einem Header sucht.

	Dazu kommt, dass es nicht genuegt, nur das Paket nochmal zu
uebertragen, das fehlerhaft war bzw. nicht erkannt wurde.  Alle Pakete,
die danach kommen, muessen nochmal gesendet werden, auch wenn sie schon
korrekt empfangen wurden.  Es koennen ein paar Pakete sein, die der
Sender schon an sein Modem abgegeben hat bevor er das `Halt, alles
nochmal' bekommt.

> Da mich aber trotzdem interressiert, wie man aus dem uucico -x9 Log
> rauslesen kann, warum es zu den Stockungen kam, poste ich hier noch
> einmal den Log.

	Aus den Unix-Logs werde ich auch nicht so ganz schlau.  Schon
das `37777777' in `rec h->cntl 37777777611' mach mich skeptisch ;-)

> pkgetpack: Connodata=1

	Wofuer das das steht habe ich auch mal gewusst - und wieder
vergessen.  Kann mal jemand nachhelfen?

> rec h->cntl 37777777642

	Der uucico hat ein Paket bekommen, in dem das Kontrollbyte
auf 242 (oktal) steht%.  Die erste 2 besagt, dass es sich um ein
Datenpaket handelt, die 4 ist die Sequenznummer dieses Paketes,
und die 2 ist die Sequenznummer des letzten Daten-Paketes, das
Dein uucico korrekt empfangen hat.

	% Das ist als signed char negativ, weil das achte Bit gesetzt
ist.  Uebergibt man in C einen solchen char an printf(), wird der zu
int erweitert, d.h. links mit Einsen (weil negativ) aufgefuellt.  Das
Ergebnis ist die 37777777 (und 6 statt 2).

> send 44

	Dein uucico hat ein Paket gesendet, das Kontrollbyte ist
044 (wieder oktal).  Die 0 kennzeichnet es als Kontrollpaket
(nur Header, keine Daten), die erste 4 steht fuer ACK, die zweite
gibt die Nummer des Paketes, dessen Empfang mit diesem ACK
bestaetigt werden soll.

[...]

> [ Das wiederholt sich jetzt munter, bis folgendes auftritt: ]
> [ Die Zahlen bei "Connodata=1" zaehlen ploetzlich weiter,   ]
> [ bei 6 tritt dann die Pause ein, und mit 1 geht es wieder weiter ]
>
> pkgetpack: Connodata=1
> rec h->cntl 37777777632
> send 43

	Paket mit Sequenznummer 3 empfangen und bestaetigt...

> pkgetpack: Connodata=1
> rec h->cntl 37777777642
> send 44

	4 empfangen und bestaetigt...

> pkgetpack: Connodata=1
> rec h->cntl 37777777652

	5 empfangen - und noch nicht bestaetigt, das wahr wohl defekt(?)...

> pkgetpack: Connodata=2
> rec h->cntl 37777777672

	6 fehlt, 7 wird wieder empfangen, aber das kann er jetzt gar
nicht brauchen...

> pkgetpack: Connodata=3
> rec h->cntl 37777777612
> pkgetpack: Connodata=4
> rec h->cntl 37777777622
> pkgetpack: Connodata=5
> rec h->cntl 37777777632
> pkgetpack: Connodata=6

	Es geht noch mehr verloren.  0 und 4 fehlen auch.

> rec h->cntl 37777777652
> send 25

	Jetzt steig' ich auch nicht mehr durch (aehem :) ).  Wieso
sendet er jetzt erst das NACK (die 2 steht dafuer)?  Und wieso bekommt
er schonwieder ein Paket mit Sequenznummer 5, er hat doch die letzte
5 bisher gar nicht bestaetigt.  Oder ist das nochmal die 5 von oben,
die der andere uucico nochmal sendet, weil er inzwischen noch kein
ACK dafuer bekommen hat?  OK, letzteres koennte ich verstehen, aber
warum das NACK so spaet?  Steckt dahinter irgendeine magische Strategie,
hab ich was voellig falsch verstanden, oder ist das wirklich so dumm,
wie es mir erscheint?

	Mit Sicherheit sind dabei einige Pakete (7?) verloren
gegangen.  Das sich das auf Dauer negativ auf den Durchsatz
auswirkt, ist klar.  Aber mir scheint, dass es durch die
Implementation schlimmer gemacht wird, als es vom g-Protokoll
aus sein muesste.  Wie gesagt, das spaete NACK irritiert mich.

[...]
> pkgetpack: Connodata=1
> rec h->cntl 37777777662
> send 46
> pkgetpack: Connodata=1
> rec h->cntl 42
> pkcntl: RR/RJ: Connodata=1
> state - [O.K.] (10)

	Ein ACK, wo kommt das denn her?

> pkgetpack: Connodata=2
> rec h->cntl 37777777672
[...]

> Also *Ich* kann daraus nichts entnehmen :-(

	Ich hab auch so meine Schwierigkeiten :)  Ich hoffe, dass
es die die Kenner jetzt ob soviel Bloedsinns nicht mehr haelt ;^)

> Jochen

	Tschuess, Gerald.

-- 
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: +49 531 796832
\X/ gm@germal.bs.open.de                      Mittagspause von 0.30 - 23.45 Uhr