Delay/disruption tolerant networking dtn im Freifunk

Hm, bei Disruptionstoleranz war meine erste Assoziation der Varon-T-Disruptor :wink: (Varon-T disruptor | Memory Alpha | Fandom)

In Protokollschichten oder Programmierung usw. stecke ich nicht wirklich drin. Bin eher ambitionierter Anwender als Entwickler.

Die doppelte Verneinung macht die technische Hürde nicht kleiner. IP ist nun einmal Ende-zu-Ende-Kommunikation in Echtzeit (Latenz im unteren Sekundenbereich, sonst schlagen, auf Applikationsebene, Timeouts zu).

(Für Mail ist das alles schon seit 30+ Jahren gelöst, Stichworte UUCP und BSMTP (und auf Internet-Seite: MX-Einträge). Statt per DFÜ mittels uucico, lassen sich die UUCP-Dateien auch per Sneakernet transportieren …)

Danke für die Stichworte, ich werde mir das alles ansehen.

Das ist auch nicht der Sinn der hier durchaus absichtlich gewählten Formulierung.
Wie Du selbst schreibst, ist der Hinweis auf Latenzen im unteren Sekundenbereich beim Thema SMTP ziemlich sinnfrei. Wenn Du meine Texte vorher gelesen hast, sollte Dir aufgefallen sein, dass ich mir darüber durchaus im Klaren bin.

Es ging darum den „hacking-Ansatz“ von christofferus zu unterstützen und nicht darum ein generisches IP-DTN Interface zu schaffen. Genau um das ausloten zu können hatte ich ihm oben eine Frage zum Projektansatz gestellt, die er auch beantwortet hat.

Wenn es Dir nur darum ging, den generell fragwürdigen Ansatz der Verbindung von IP und DTN zu unterstreichen - your point :wink:

Hört sich mehr nach battlefield management als Freifunk an :smile:

1 „Gefällt mir“

Beisst Euch doch nicht an einer konkreten Funktechnik fest.
Besser die Funk-Technik auf einem AdHoc-Ansatz lassen und das Store&Forward samt Fehlertoleranz ein Layer höher hinlegen.

Ich würde nicht Packet-Radio vorschlagen, sondern eher

  • IP (v6, stateless autoconfig/linklocal)
  • UUCP over IP
  • routing mit pathalias via maps-schnipsel
  • RZBSMTP für die Mails
  • In den Mails dann 7plus
  • ggf. Überbau mit Trans-X (habe ich aber schon 25 Jahre nicht mehr genutzt…)

Das ist ja auch eher der Ansatz von @christofferus.

Der Packet-Radio-Vorschlag geht in seinem Zusammenhang auch IMHO nicht auf. Das wäre eher eine Alternative für eine Langstrecken-Daueranbindung, nicht für store’n’forward oder sehe ich das falsch?

UUCP/Pathalias als Unterbau war auch @wusel’s Vorschlag und bisher wahrscheinlich auch der generisch sinnvollste.

@christofferus bastelt grade noch mit ION-DTN und möchte das wohl gerne einsetzen - mal schauen was dabei rumkommt.

Bei deinem Vorschlag stehe ich bei Trans-X voll auf dem Schlauch, mir fällt da nur „living on video“ aus den 80ern zu ein, was Du mit hoher Sicherheit nicht meinst.

1 „Gefällt mir“

Vielleicht haben wir uns bei unseren Förderungen nur immer auf die falschen Schwerpunkte konzentriert. Hinterher standen wir dann immer mit Leuten da, die möglichst schnell bei Youtube und Netflix schauen wollten.
Die da oben in dem Video haben aber offensichtlich Interesse an echtem Mesh, und lokalen Diensten. Und nehmen den von einigen Altvorderen gepflegten Faible für die Zombieapokalypse ernst. Wobei sie die sogar selbst herbeizuführen versuchen.

2 „Gefällt mir“