![[Startseite]](/logo/bilklogokl2.gif "zur Startseite"){kind=logo}
Allen, die es noch nicht wissen, möchte ich gerne die Geschichte der Entstehung des rfc "IP over beer crate" erzählen. Diejenigen, die es schon wissen, mögen Gefallen daran finden, oder eben nicht. Diejenigen, die dabei waren, mögen mich korrigieren, wo ich Einzelheiten nicht mehr weiss. Diejenigen, die es nicht interessiert, klicken bitte einfach weiter und meckern hier nicht rum, ja?
2001-07-28 Also, das war so: Wir sassen bei einem guten Godefroy und einer Hommingberger Gepardenforelle im Biergarten vor dem Saloon bei der "Moulin de la Falize" in Bouillon rum. Das waren Sven, Alex, Jürgen, Reinhold und ich. Wir bereiteten die Linuxbierwanderung 2001 vor und überlegten verzweifelt, wie wir eine Netzwerkverbindung vom Archeoscope, unserem Tagungsort unten im Tal, zum Camping-Platz "Moulin de la Falize" oben auf dem Berg hinfrickeln könnten. Es ging um ca. 1500 m Entfernung und 120 m Höhenunterschied. Es bestand Sichtkontakt.
Wir prüften verschiedene legale und, ganz kurz und nur hypothetisch, auch einige illegale Möglichkeiten.
Nach zwei weiteren Runden Godefroy fiel uns dann ein, was Bouillon uns in kaum begrenzter Quantität 24/7 bieten konnte: Genau das. Das Bier. Godefroy.
Das Problem war jetzt, eine IP-Lösung over Brauerei/Bier/Flaschen/irgendetwas zu basteln. Die Hardware musste genormt, von den Einhemischen anerkannt, allgemein bekannt, leicht transportabel und zur Aufnahme von Daten geeignet sein. Hier bot sich nur eins an: Der gemeine "Bierkasten".
Vier Reihen a fünf Fächer in so einem Kasten sind ja immerhin 20 bit:
keine_flasche_im_fach=0 flasche_im_fach=1
Ein Blick auf die nächste Runde Godefroy zeigte, dass eine Kiste Godefroy, unter Berücksichtigung des kaum zu vermeidenden Overhead, weder unter gastronomischen, noch unter datenfernübertragungstechnischen Gesichtspunkten eine relevante Menge darstellte. Als wir auch diese Runde getrunken hatten, fiel es uns wie Leergut aus dem Kasten: Wir haben mehr als zwei Betriebszustände!
keine_flasche_im_fach=0 leere_flasche_im_fach=1 volle_flasche_im_fach=2
Dies ist zwar eine Konstellation, für die die Logistik der Brauereien eher selten konzipiert ist, aber es ging ja auch nicht um den Transport von Bier (was als Nebenprodukt netterweise auch anfällt), sondern um den Transport von Daten.
Wir gaben die leeren Flaschen nicht an den Service zurück, sondern stellten sie zu Testzwecken auf dem Tisch auf und orderten eine weitere Runde, weil wir keine vollen Flaschen mehr hatten. Die Kellnerin bot uns an, gleich einen ganzen Kasten zu servieren. Gute Idee! Wir bestellten einen leeren Kasten. Es kann nicht nur an den Sprachschwierigkeiten gelegen haben, dass es etwas dauerte, bis sie diese Bestellung aufnahm. "Nein, einen leeren Kasten. Bitte auch keine leeren Flaschen darin. Wir wollen da mal was testen..."
Den sehr merkwürdigen Blick, mit dem die Kellnerin den leeren Kasten servierte, ignorierten wir souverän und begannen mit der Begutachtung der Hardware. Sofort zeigte sich ein Problem, das bei TCP-IP normalerweise nicht auftritt: Je nachdem, wierum der Empfänger den Kasten hält, ergibt die Decodierung verschiedene Ergebnisse, weil die bits ja nicht als Stream, sondern als komplettes Paket synchron aufschlagen. Wo, bitteschön, ist da der Anfang?
Das war der Punkt, an dem wir beschlossen, diese und alle weiteren Einzelheiten in einem rfc festzuhalten.
Das Problem mit der Konvertierung der 20 Kastenfächer in einem Stream lösten wir mit der Definition von "oben links" als 1. Bit und einem leeren Fach als dessen Kennzeichnung. Sofort trat ein neues Problem auf. Was ist, wenn unten rechts auch ein leeres Fach ist? Wir definierten: Das darf nicht sein. Also darf in den Daten kein "leeres Fach" vorkommen.
keine_flasche_im_fach=Stream-Beginn leere_flasche_im_fach=0 volle_flasche_im_fach=1
Der geneigte Leser wird bemerken, dass damit für die Codierung doch wieder nur zwei Betriebszustände zur Verfügung stehen. Wir merkten es auch. Beim nächsten Godefroy. Einer pfefferte wütend seine leere Flasche in den Kasten. Sie landete mit der Öffnung nach unten. Es schepperte ziemlich laut. Die Kellnerin starrte uns an... Wir starrten auf den Kasten... Das war die Lösung!
keine_flasche_im_fach=Stream-Beginn leere_flasche_im_fach_richtigrum=0 volle_flasche_im_fach_richtigrum=1 leere_flasche_im_fach_falschrum=2 volle_flasche_im_fach_falschrum=3
Mein lieber Scholli! Das wird ja richtig Bandbreite! Mutig jubelnd betraten wir datenfernübertragungstechnisches Neuland und orderten eine Runde Godefroy. Die Kellnerin liess sich weinend ablösen. Wir hatten also 20 hoch 4 bits pro Kasten. Ähh... Nicht ganz. Das erste Fach fällt ja weg, also 19 hoch 5. Hmm... Lässt sich da nicht was dann drehen? Einer bemühte die Grundlagen der Mathematik und fand heraus, dass 18 hoch 5 eindeutig mehr ist als 19 hoch 4. Als der neue Kellner die nächste Runde brachte, bestätigte er die diese Rechnung.
Also beschlossen wir, die Fächer paarweise zusammenzufassen. Die ersten beiden Fächer bleiben zur Kennzeichnung des Anfangs leer. Also gilt:
stream_begin=00 <alle_anderen_zeichen>=[0-4,0-4]
Damit stand der Betriebszustand "leeres Fach" auch wieder zur Verfügung. Durch das paarweise Zusammenfassen der Fächer hatten wir also 9 hoch 8 bits pro Kasten zur Verfügung. Das war ja... mal nachrechnen... tatsächlich! Der komplette ASCII-Zeichensatz kann nachgebildet werden!
"IP over beer crate" war geboren! Ich erklärte mich bereit, am Tage der zu dokumentierenden Umsetzung des rfc mit meiner Kasten-Ente den carrier zu spielen und die packets vom Archeoscope zum Camping-Platz hin- und herzukarren.
(Das Gerücht, dass ich in diesem Zustand fortgeschrittener Euphorie auch bereit war, die Ente anzukurbeln und alle nach Hause zu fahren, dementiere ich hiermit nochmals heftigst!)
Wir besprachen noch einige unwesentliche Feinheiten:
Eine Weile dachten wir noch über die Codierung und Decodierung der Daten nach. Beim Absender kommen Daten aus dem IP-Stack und werden von Hand in das beer crate-Format konvertiert. Beim Empfänger wäre eine Automatisierung denkbar: Eine Kamera mit der entsprechenden Software müsste in der Lage sein, zwischen leeren Fächern, Flaschen ohne Kronkorken, Flaschen mit Kronkorken, und Flaschen mit dem Boden nach oben zu unterscheiden.
Wir berieten noch eine Weile über die Frage, wie die Software anhand des Flaschenbodens erkennen könnte, ob die Flasche leer oder voll ist. Hm... Wir beschlossen, auf den Sponsor für die zweite Kamera zu warten, die den Kasten von unten aufnimmt, weil von dort die umgedrehten Flaschen wieder mit und ohne Kronkorken zu sehen sind. Ein kurzer Test bestätigte das: Volle Flaschen kommen in diesem Fall (also ohne Kronkorken, aber umgedreht) wirklich leer beim Empfänger an.
Der Kellner wischte die Ergebnisse unserer Tests auf dem Tisch weg, räumte die Teller mit den Hommingberger Gepardenforelle ab und empfahl uns, das Problem erst am nächsten Tag zu lösen. Wir ignorierten diesen billigen Trick, den Feierabend vorzuziehen, und fragten ihn, ob er als gastronomy consultant nicht einen Kontakt zur Brauerei vermitteln könne, damit wir diese als sponsor gewinnen könnten. Er meinte, dies habe keinen Zweck, weil alle umsonst saufen wollen und er wolle jetzt kassieren.
Das rfc committee beschloss, die Zeche zu bezahlen, und am nächsten Tag erneut zusammenzutreten. Der Antrag, einen frischen Kellner zu bestellen, fand keine Mehrheit.
2001-07-29 Der nächste Tag war mit 30 Grad ähnlich heiss und sonnig, deshalb schauten wir uns immer mit blinzelnden Augen an. Aus Gründen der Übersichtlichkeit beschlossen wir, eventuell nötige weitere Tests mit Wasser- oder Colaflaschen durchzuführen. Ansonsten beschränkten wir uns auf Hommingberger Gepardenforelle.
Wir hatten uns vorgenommen, unsere todo list zu komplettieren und die Prioritäten zu sortieren:
Zur allgemeinen Erleichterung stellten wir fest, dass es sich in jedem Fall um eine point to point-Verbindung handelt, sodass wir routing-Probleme ignorieren konnten. Der carrier ist auch dazu ausgelegt, verstopfte Knoten eigenständig zu umrouten.
<to be continued>
Tja, und irgendwie nahm sich Yalla auf der LBW 2001 in Bouillon dieses Themas nochmals an, bekam die Software aber nicht fertiggestellt. Trotz (oder wegen?) reichlicher Tests am Objekt.
Text und Photo: Rainer Kersten
released under the terms of GPL
![[www.woodshed.de]](/but/woodshed.jpg "woodshed productions liefert www-Seiten"){kind=small}
Startseite ·
Impressum ·
Kontakt/Mail ·
Archiv ·
Holpellets ·
URL vorschlagen