Hallo,
ich suche nach Möglichkeiten ein unterbrechungstolerantes Netzwerk aufzubauen.
Das Thema ist für mich einfach noch unüberschaubar und ich erhoffe mir ein paat Tips aus der Community.
Ziel ist es, dass mindestens eine e-mail-kommunikation möglich ist über store-carry-forward-routing.
Im ff-mesh auf der einen Seite, soll ein Knoten die mails aus dem Netz, die z.B. von Linuxrechnern aus Thunderbird heraus versendet wurden entgegennehmen
ein oder mehrere bewegliche Knoten sollen die Verbindung überbrücken z.B. mit dem Fahrrad, Auto, Zug, Flugzeug, Drohne indem sie die daten am Endknoten A synchronisieren.
auf der anderen Seite sollen dan wieder am Endknoten B eine Synchronisation erfolgen in ein anderes FF-mesh.
Ich bin auf diverse Dinge gestossen, aber irgendwie reicht bisher mein Horizont nicht aus, das umzusetzen.
ION-DTN, DTN2 sind zwei der Ansätze. Sowas gab es irgendwie schon mit KioskNet, DieselNet und anderen, aber auch da gerate ich immer in Sackgassen. Ich denke aber, wenn einer sich mit Protokollen usw. auskennt, dann versteht er schnell, worum es geht und könnte mit mir sowas aufziehen.
Ich würde gerne eine Art mesh-verbund sehen, also jeder Knoten soll eigentlich identisch sein, realisiert z.B. durch Raspberry Pi und Co um eine schnelle Multiplikation zu erreichen, denn es soll ja für andere schnell und einfach umzusetzen gehen. Am Ende könnte eine Out-of-the-box-Lösung herauskommen. Gerade in Hinblick auf die Anbindung nicht versorgter Regionen dieser Erde, sehe ich in Verbindung mit Mesh-netzen einen grossen Nutzen in DTN. Mit einer ggf. speziell angepassten FF-Firmware könnte zudem hinter jedem Endknoten eine komplette Kommunikationsinfrastruktur entstehen um lokal vernetzt zu sein.
Ich glaube, Du bringst da verschiedene Ebenen durcheinander; Freifunk funktioniert auf Layer 2 bis 3, und da beschreibt ein RFC ganz gut die Problematik: rfc1149
Du scheinst aber eher klassisches Store-and-Forward im Blick zu haben (siehe Mail-Beispiel), das wäre dann eher was ‚höheres‘ wie UUCP für generischen Datentransport?
Edit:
Die „Radios“ kannst durch die ESP ersetzen.
Wobei Du über CB mehr als die 10x Reichweite von Wlan hinaus kommst.
Allerdings nur 1k2 oder 2k4 Baud
Naja, ich wollte nur aufzeigen, dass es in einer oder besser zwei Freifunknetzen eine sinnvolle Verwendung geben kann.
Ums durcheinanderbringen ging es mir da nicht.
Grundsätzlich geht es mir natürlich erstmal nur um klassische Store-Carry-Forward. Es sollte nur wenn möglich nahtlos zu Freifunk passen, denn wenn man zwei isolierte meshnetze (zwei Dörfer) verbinden will, sollte dann im jeweiligen Dorf schon ein klassisches meshnetwork laufen. Die müssen ja nicht von Haus zu Haus mit Store-Carry-Forward arbeiten, wenn es mesh gibt.
Wie gesagt, mit IP, dem Grundprotokoll bei Freifunk, hat ‚dtn‘ AFAICS nichts zu tun. Natürlich kann man eine Kabelverbindung auch durch einen 1500-Byte-Speicher in einem E-Mobil ersetzen und jedes IP-Paket zwischen Sender und Empfänger per Medientransport austauschen – IPoAC-Ansatz –, aber IP eignet sich dafür nicht. Mails sind eine Option, oder beliebige Dateien — aber für IP-basierte Dienste ist die Latenz viel zu hoch. Eine Eisenbahn, die im Kreis führe, mit mehreren Zügen in festem Abstand, das könnte für IP funktionieren …
ok, ja, das habe ich verstanden, drum braucht es ja z.B. ION DTN, das ist für hohe Latenzen ausgelegt, aber ich komme da technisch nicht weiter. Email ist damit sicher am leichtesten Umzusetzen aber auch das muss ich erstmal irgendwie aufbauen.
Hab mal kurz in RFC 4838 geschnüffelt und stolpere direkt über zwei Dinge, auf das eine versucht Wusel dich bereits hinzuweisen:
3.1. Virtual Message Switching Using Store-and-Forward Operation A DTN-enabled application …
While IP networks are based on „store-and-forward“ operation, there
is an assumption that the „storing“ will not persist for more than a
modest amount of time, on the order of the queuing and transmission
delay. In contrast, the DTN architecture does not expect that
network links are always available or reliable, and instead expects
that nodes may choose to store bundles for some time
Ich habe mich nie mit ION-DTN beschäftigt, aber die RFC legt nahe, dass hier eine spezielle Applikations-Schnittstelle vorausgesetzt wird.
Weiterhin steht der Ansatz wie Wusel Dir schon sagt „in contrast“ zu IP, was nun mal fester Bestandteil von FF ist und von den meisten netzwerkfähigen Applikationen vorausgesetzt wird.
Somit sehe ich zwei große Hürden für deinen Ansatz:
Du musst eine definierte Schnittstelle entwickeln, die auf Layer3+ zwischen dem IP-Netz und dem DTN fungiert und in allen beteiligten Applikationen dafür sorgen, dass diese DTN-aware bzw. sogar DTN-enabled sind.
Das sehe ich auch so. Ich denke, das wird wohl ein grösseres Projekt.
Inzwischen habe ich zwei VM mit der Technik verbunden und ein paar Daten hin und her gesendet. Das klappte soweit besser als erwartet.
Ich werde mich jetzt mal weiter damit beschäftigen.
Offenbar bin ich auf dem richtigen weg. Ob Standardapplikationen das nutzen können oder es spezielle Applikationen benötigt, soweit bin ich noch nicht. Email wäre natürlich schon mal toll. Aber jetzt sehe ich das erste mal Land und weiss, dass ich weitermachen werde. Für Überlegungen die Applikationen betreffend ist es wahrscheinlich zu früh. Bin aber für alle Tips und Hinweise offen.
Ich plane alle wesentlichen Fortschritte in Form von Step-by-Step-Anleitungen publizieren.
nächste Nahziele:
kleines RaspberryPi DTN-Netz mit 2 später 3 Knoten mit WLansticks
Daten mittels eines dritten mobilen Knoten bewegen
Einfache Textdaten von VM in FF-mesh(offline) an VM in FF-mesh(online) senden und empfangen über diese RaspberryPi-Knoten
Ist das ein Projekt mit einem konkreten Ziel oder eher ein „learning by doing“ Ansatz um zu sehen wie weit Du mit Verknüpfung vorhandener Projekte kommst?
Es ist erstmal ein learning by doing Projekt. Ich plane die Fortschritte im Anschluss so zu dokumentieren, dass sie durch jeden Step by Step nachgeführt werden können.
Ich möchte mindestens eine Kommunikationsanwendung einbinden um Text und Daten auszutauschen. Eine e-mail-lösung wäre natürlich das beste, wohl aber auch nicht das einfachste.
Es gibt noch kein konkretes Projekt, ich möchte niemanden enttäuschen, wenn es scheitert, lieber mit einer funktionierenden Lösung aufwarten, aber ich denke, wenn man alles erforderliche in eine Bananenkiste packen kann um ein isoliertes Netz mit einem Internetknoten zu verbinden, z.B. Keller, abgelegene Region, Krisenregion etc., dann wird es schnell Projekte geben, die von der Out-of-the-box-lösung partizipieren könnten.
So auf die Schnelle: Es klingt nach einem „normalen“ Store-and-Forward-Konzept.
Schau doch mal bei den Funkamateuren, die schon zu Ur-Zeiten mit Packetradio und folgenden Konzepten Store-and-Forward in Verbindung mit Funk (aber auch Leitungswegen) entwickelt haben. Aktuell ist Hamnet ggf. ein Projekt, was Du Dir ansehen solltest. Und wenn es nur zum Vergleich ist, wie andere die gleichen Probleme bereits gelöst haben.
Allerdings finde ich nichts zum Thema Disruptiontoleranz. Ist es denn Möglich im Hamnet Daten über mobile Knoten zu transportieren, auch wenn zeitweise weder Kontakt zum Sender, noch zum Empfänger besteht?
Einen „IP - DTN - IP“ SMTP-Transport zu entwickeln scheint mir nicht unrealistisch. Ich lese mich mal ein wenig ein, wenn sich dabei keine logik-Hürden finden und es die Zeit erlaubt, versuche ich mal was auf die Beine zu stellen. Dafür müsste es aber in beiden IP-Netzen auf jeden Fall Mailserver geben, die entsprechend lange SMTP-Vorhaltezeiten haben. Das wäre aber eine reine Konfigurations-Frage.
Wenn ich die Zeit dazu finde, hänge ich mich mal mit ein wenn Du magst.
Ich bin für jeden Input dankbar.
Ich fände es sinnvoll, wenn am Ende jeder, der es brauchen kann davon partizipiert. Also steht für mich eine Anleitung zum Aufbau und der Installation im Vordergrund. Es darf auch gerne etwas dauern.
Ich kann bisher nur / oder immerhin mit zwei virtuellen Maschinen dienen mit Debian 9 und der ION-DTN installation.
Ich kann dank einer Anleitung inzwischen zwischen diesen beiden Maschinen Daten über das Bundelprotokoll austauschen. Zu mehr bin ich bisher noch nicht gekommen, es ist auch aufgrund von deadlinks und mangels Anleitungen ein ziemlicher Jungel.
Vielleicht wäre es geschickt diese ersten Schritte schonmal zu beschreiben und auf einer Webseite zu präsentieren. Dann ist der erste Einstieg schon mal ganz easy.
