Das 'g'-Protokoll ----------------- Das 'g'-Protokoll ist das Standardprotokoll fr UUCP. Alle mir bekannte Systeme beherrschen es (zumindest teilweise). Das 'g'-Protokoll sendet Daten in Paketen, die Gr”že der Pakete kann zwischen 32 Byte und 4 kByte liegen. Zusammen mit der Fenstergr”že ist die richtige Wahl der Paketgr”že entscheidend fr die Geschwindigkeit. Die Datenpakete sind mit mehreren Mechanismen zur Erkennung von šbertragungsfehlern versehen und mssen vom Empf„nger (Slave) geprfte und best„tigt werden. Damit bei fehlerfreien šbertragungen der Master durch das Warten auf die Best„tigung nicht ausgebremst wird, kann mit der Fenster- gr”že angegeben werden, wieviel Datenpakete der Master senden darf, bevor er eine Best„tigung fr das erste Paket abwarten muž. Es k”nnen also mehrere Pakete direkt hintereinander verschickt werden. Auf diese Weise kann das 'g'-Protokoll bei fehlerfreien sehr schnell werden. Der Nachteil dieses Verfahrens tritt erst bei šbertragungsfehlern auf. Bei ungnstiger Konfiguration der Paket- und Fenstergr”že kann die šbertragung stark gebremst werden. Erh„lt der Master keine Best„tigung fr ein Paket, oder die Nachricht, daž es fehlerhaft empfangen wurde, so muž er alle Pakete ab dem fehlerhaften Paket nocheinmal senden. Im "worst case" muž er maximal die Anzahl der mit Fenstergr”že eingestellen Pakete versenden. Es ist also zweckm„žig, die Paket- und Fenstergr”že nicht zu grož zu w„hlen. Sie sollten gerade so grož sein, daž es bei einer fehlerfreien šbertragung nicht zu Verz”gerungen kommt. Treten h„ufiger Fehler auf, ist es eher zweckm„žig, die Paketgr”že zu verringern, denn die Fenstergr”že. Die Chance, das so mehr korrekte Pakete bertragen werden, ist gr”žer. Gute Werte erreicht man beispielsweise bei einer 14400er-Verbindung mit Paketgr”žen von 1024 Byte und Fenstergr”že 5. Grožen Einfluž hat auch die Puffergr”že fr die seriellen Schnitt- stellen auf Sender- und Empf„ngersystem. Tritt ein Fehler auf und muž der Master Pakete neusenden, so wird natrlich erst alles bertragen, was schon im Puffer ist (es wird dann auf der Empf„ngerseite verworfen). Der Sendepuffer sollte daher nicht zu grož sein (und je nach Rechnergeschwindigkeit zwischen einem und drei Paketen fassen). Der Empfangspuffer dagegen darf ruhig grož gew„hlt werden. Hier bringt ein grožer Puffer nur Vorteile. Die feste Paketgr”že wird von einigen wenigen UUCP-Systemen verlangt (sie k”nnen es nicht besser). Wenn m”glich, sollte man darauf verzichten. Muž man sie benutzen, sollte man die Paketgr”že nicht zu grož w„hlen (ich empfehle max. 512 Byte). .