🚀 go-pugleaf

In de.comm.uucp, article <MNRzr*PY1@germal.bs.open.de>,
  gm@germal.bs.open.de (Gerald Malitz) writes:
> 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.
> 
Das stimmt nicht ganz. Das erste Paket wird eine fehlerhafte Pruefsumme
haben; der uucico sollte(!!) dann eigentlich in den Daten dieses Pakets nach
einem vernuenftigen Header suchen und den dann als Paketanfang erkennen.

Nur leider ist das bschissen implementiert und funktioniert nur dann, wenn
mehr als 6 Zeichen verlorengehen, weil der Header nicht komplett im Puffer
ist. Taylor-UUCP macht es richtig.

> 	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.
> 
Stimmt -- das selektive Neuuebertragen ist zwar vorgesehen, wurde aber nie
implementiert. V.42 hat es als optionales Feature.

> > 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 ;-)
> 
Das ist typisch Vorzeichenerweiterung eines chars und hat damit zu tun, dass
diverse Idioten vergessen haben, an den entsprechenden Stellen ein &0377
dazuzuschreiben.

> > pkgetpack: Connodata=1
> 
> 	Wofuer das das steht habe ich auch mal gewusst - und wieder
> vergessen.  Kann mal jemand nachhelfen?
> 
 /* Continuous Non Valid Data Count */
Wird erhoeht, wenn ein Header mit ungueltiger Headerpruefsumme gefunden wird;
also im Normalfall immer, wenn nach einem Fehler ein 0x10 in den Daten des
Paeckchens auftaucht.

> > 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.
> 
Korrektur bitte -- die Nummer deines Pakets, das die Gegenstation korrekt
empfangen hat.

> > 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?
> 
Das passiert dann, wenn zwar der Header OK aber die Datenpruefsumme nicht OK
war oder irgendwas mit partiellen Paketen passiert ist (der betreffende 
Code ist extrem undurchsichtig).

> > 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?
> 
Gute Frage...


Versuch mal, die Windowgroesse von 7 auf 6 zu senken. Ich habe bemerkt, dass
es unter manchen Bedingungen damit Probleme geben kann.

-- 
"All of the books in the world contain no more information than is broadcast as
 video in a single large American city in a single year. Not all bits have equal
 value."
-- Carl Sagan
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/