> Mir ist klar, dass vieles über unsere Treffen läuft und manche Dinge > daher für Leute, die nicht bei Treffen sind, nicht transparent > abzulaufen scheint. Verbesserungsvorschläge sind willkommen.
Die Treffen im Mumble oder im IRC abzuhalten würde die Transparenz drastisch erhöhen. Ergebnisse, Bedarfe und Erkenntnisse, mehr als bisher, auf der Liste zu kommunizieren hilft sicher auch. Und wieso schickst du mir die Liste mit den möglicherweise offenen Fragen zur Netzsegmentierung privat? Unter anderem für sowas ist diese Liste hier da. Die Wahrscheinlichkleit ist groß, dass die meisten Fragen andere besser beantworten können, als ich. Deswegen antworte ich einfach mal hier, um die Diskussion zu starten: > * Finden Knoten mit Geokoordinaten automatisch "ihre" Subcommunity? > ** Was ist mit Knoten ohne Geokoordinaten? Kommnt drauf an, wie autoritär ma es gerne hätte (und ob ma eher möglichst viele Knoten mit oder ohne Koordinaten haben will - siehe Rausschmiss von Neuknoten außerhalb der offiziellen Hamburger Stadtgrenze und Workaround mittels Eintragung ohne Koordinaten). Ich bin natürlich dafür, dass die Leute sich selbst aussuchen, in welchen Meshes ihre Knoten sind (oder sein könnten, wenn dort ein Mesh wäre). Eine flächige Segmentierung Deutschlands (und darauf läufts langfristig zwingend hinaus), ist ohne Punkte, an denen sich mindestens drei Segmente berühren, eh nicht möglich - und dort sehen Nutzer dann drei verschiedene Freifunk-Meshes, die sich praktisch immer irgendwie auch überlappen werden. Es ist vermutlich trotzdem sinnvoll, bei einer Teilung die initiale Segmentzugehörigkeit automatisch anhand der der Geodaten vorzunehmen und dem Knotenbetreiber die Möglichkeit zu bieten, im Config-Mode ein anderes Segment zu wählen. Leider sind die echten Meshes nicht ausgeprägt genug, um anhand der Sichtbarkeit der Nodes untereinander auch Nodes ohne Geodaten lokalisieren zu können. Trackingdaten von roamenden Clients wären dafür natürlich auch extrem gut geeignet - aber bereits die Erhebung dieser Daten widerspräche unseren Grundsätzen und ist deshalb ein Nogo. Nicht zuordbare Nodes könnte man zufällig eines der neuen Segmente zuweisen und würde bei einer Zweiteilung immerhin noch zur Hälfte richtig liegen (und viel besser wird eine Automatik ohne irgendwelche Stützdaten nicht werden können). Für reine Meshnodes wäre denkbar, dass sie zwar ebenfalls initial eine zufällige Segmentzuteilung erhalten, beim ersten Kontakt mit einem Uplinknode aber dessen Segment übernehmen. In allen Fällen würdemn aufmerksame Knotenbetreiber fehlerhafte Zuteilungen korrigieren. > ** Wenn nicht: Funktioniert manuelles wählen der Subcommunity? Manuelles wählen der Community funktioniert bereits recht gut - selbst die rausgeworfenen Hamburger Knoten, von denen ich weiß, waren recht nah an Hamburg drann. Ich gehe davon aus, dass eine technische Implementierung der Subcommunities als Hauptcommunity am einfachsten wäre. Das eigendliche Problem sind die Splits. Vermutlich sind alle par Jahre neue Teilungen einzelner Segmente nötig. Vieleicht macht es Sinn von Anfang an nicht das momentan gewünschte Segment, sondern jenes zu wählen, dass bei "Vollausbau" dort sein wird, wo der Knoten steht. Zu klären wäre dabei, wie feingranular das Zielraster sein darf, bevor es zu personenbeziehbar wird. Stadtteile sind ziemlich sicher okay - aber ob stadtteilgroße Segmente in zwanzig Jahren zu groß sein werden oder der technische Fortschritt die Segmentierung überflüssig machen wird, ist heute noch nicht sicher... > * Was sind gute Grenzen? Wenn man Abgrenzung will, sind die funktechnisch besten Grenzen: - Erhebungen (gibts hier wohl eher nicht) - Wälder (okay, wir haben Parks und bei WLAN reicht im Sommer auch schon mal n einreihiger Knick als Barriere) - geschlossene und möglichst massive Bebauung Wenn man Intermeshnodes einsetzen will, sind die funktechnisch besten "Grenzen" wohl: - Flüsse - versiegelte Flächen (Straßen, Plätze) Sowohl funktechnisch, als auch organisatorisch ist eine ordentliche Abgrenzung der Segemente innerhalb eines stadtgebiets auch mit Alster und elbe nahezu unmöglich und auch nicht kompatibel mit dem (von mir) präferierten Selbstwahl-Modell. Wenn die Kanäle der Sub-Communities geschickt gewählt werden, kann man allerdings die Nachteile der Überlappung abmildern, braucht die Segmentgrenzen nicht ganz so exakt festzulegen und vereinfacht den Betrieb von Intermeshnodes. > ** Zweiteilung an der Elbe führt zu verschieden großen Subcommunities > -> Dreiteilung an Elbe und Alster? Die Subcommunities müssen nicht gleichgroß sein. Ma bräuchte nur eine ordentliche Strategie für die weiteren zukünftigen Teilungen. Leider kann ma nicht von Anfang an die endgültige Segmentanzahl realisieren, weil die meisten Segmente dann initial viel zu klein wären, was deren Wachstum nachhaltig behindern würde. Elbe und Alster sind natürliche Grenzen, mit denen auch der potentiellen Knotenbetreiber sofort klar kommen dürfte. Postleitzahlenbereiche, Bezirke (und später auch Stadtteile) eignen sich für die Definition grenzüberlappender Segmente vermutlich auch gut. Hier schon mal die Bezirke: <https://de.wikipedia.org/wiki/Datei:Hamburg,_administrative_divisions_%28%2Bdistricts_-%2Bboroughs_-pop%29_-_de_-_colored.svg> > * Führt die Umstellung zu verschiedenen Firmwares oder kann man die > Subcommunity im Config-Mode wählen? Am komfortabelsten für Knotenbetreiber und entwickler wäre wohl die Config-Mode-Lösung. > * Howto mesh über Subcommunitygrenzen hinweg? Intermeshnodes könnten auf verschiedene Arten realisiert werden: - gewöhnliche Singlemeshnodes werden mit einer Routernode verbunden, die dann zwischen den Meshes routet. - Multichannelfähige Multimeshnodes routen zwischen den sichtbaren Meshes. Gibt es preiswerte Router, die auf einem Band (also 2.4 GHz oder 5 GHz) mehrere Kanäle für verschiedene Meshnetze nutzen können? Das Problem ist, das Routing selbstkonfigurierend zu implementieren. Die einzelnen Segmente wären sowas, wie im Internet die autonomen Systeme. Aber es gäbe keine zentrale Instanz, die die Routen verwaltet. Die Intermeshnodes müssten sich irgendwie absprechen. Das Problem ist ähnlich dem bei der verteilten IP4-Vergabe ohne Gatewaymitwirkung - ich hab aber vergessen, ob und wie es gelöst wurde. > Einige Communities haben sich schon mehrfach geteilt. Dort kann man > bestimmt abschreiben... Möglichwerweise. Welche Communities sind das? -- Allan Wegan <http://www.allanwegan.de/> Jabber: [email protected] OTR-Fingerprint: E4DCAA40 4859428E B3912896 F2498604 8CAA126F Jabber: [email protected] OTR-Fingerprint: A1AAA1B9 C067F988 4A424D33 98343469 29164587 ICQ: 209459114 OTR-Fingerprint: 71DE5B5E 67D6D758 A93BF1CE 7DA06625 205AC6EC
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Freifunk mailing list [email protected] https://www.hamburg.ccc.de/mailman/listinfo/freifunk
