Hood-Bildung - SSIDs
Christian Dresel
fff at chrisi01.de
Do Sep 20 10:10:04 CEST 2018
hi
kurz und bündig weiterhin ist meine Meinung:
Es darf, soll und muss jeden frei gelassen werden, wie er seine SSID
setzt. Ich lasse mir nicht vorschreiben was ich in meinen Gebiet setze
und ich trage auch (nahezu) alles in den keyxchange ein wo ich das
Gefühl habe das es passt. Paar Ausnamen:
- Rechtswiedrige SSID egal welcher Art (Beleidungen u.ä. inkl.)
- Es kommt nicht das Wort "Freifunk" drinnen vor, wenn es gut begründet
wird bin ich aber sogar dafür offen und würde es nach Rücksprache mit
weiteren Leuten dann dennoch eintragen
- Ich hab vorher schon mitbekommen, das man sich auf die SSID nicht
geeinigt hat / es streit darüber gab / etc. dann muss man das auch erst
lösen, da trag ich dann vermutlich gar nix ein bis es geklärt ist.
- vllt. hab ich noch iwas vergessen, das wird sich dann aber schon
ergeben das ich mal eben ins stocken komme...
Ansonsten ist es mir egal ob Hof ein komplett anderes Konzept als
Würzburg oder Fürth fährt, egal was BGL macht oder wie es die Nürnberger
sehen, egal was Erlangen und Forchheim macht. Das soll jeder für sich
entscheiden.
Daher finde ich, man braucht darüber nicht diskutieren, das sollte eher
jeder Bereich für sich entscheiden (z.b. hat Forchheim das sehr schön im
eigenen Kreis für sich entschieden und es nicht ganz Franken
"aufgezwungen" was mir gut gefällt, auch wir hier in Fürth haben unsere
Meinung und nutzen das wie wir es wollen, genauso sollte es auch wo
anders sein.)
mfg
Christian
On 20.09.2018 09:43, Sebastian Beck wrote:
> Hallo,
>
> Mir gefällt die Idee erstmal gut.
>
> Realisierbar scheint sie auch zu sein.
>
> Mit diesem Ansatz würden wir sehr viele neue Hoods erstellen, die dann
> auch wieder SSIDs brauchen.
> Deswegen möchte ich ne parallele Diskussion starten.
>
> Ja, der Ersteller hat erstmal den Vorzug und darf diese frei vergeben.
> Aber mit unserer v2 Umstellung entsteht gerade auch ein SSID Zoo.
>
> Ich glaube immer noch an die Markenkraft der SSID und dass viele sich
> zumindest annähern möchten.
>
> Auch war es bisher das beste Bauchgefühl mangels Vorgabe (zumindest für
> meinen Teil).
>
> Wir könnten die Situation nutzen und einfach mit 2-3 doodles was
> gemeinsames finden.
>
> Gibt es jemanden, der von vornherein sagt, er möchte das nicht?
>
> Grüße, Sebastian
>
>
> Am 20. September 2018 09:23:11 MESZ schrieb Christian Dresel
> <fff at chrisi01.de>:
>
> hi
>
> On 20.09.2018 09:11, Steffen Winkler wrote:
>
> Hallo Christian,
>
> das kann ich Dir genau sagen. Wenn es um Automatisierung geht,
> will man
> doch das Problem lösen und kein neues schaffen.
>
>
> ich seh in meinen Konzept gerade kein neues Problem. Wenn man eine Hood
> anlegt/löscht/ändert muss man halt noch den Cache danach leeren, das ist
> im phpmyadmin ein Klick. Die Hood anlegen ist da viel viel mehr Arbeit
> (zur Info: Hoods automatisiert anlegen geht nicht, woher soll man die
> Gatewaydaten automatisiert wissen? Ne das wird für immer manuell bleiben)
>
>
> Das Problem ist, dass
> die Berechnung zu viel Rechenzeit beansprucht. Das wird durch
> den Cache
> gelöst.
>
>
> exakt, passiert ja in meinen Vorschlag genau so. Statt alle 5 Minuten wo
> sich jeder Uplinkrouter meldet und man so alle 5 Minuten für jeden
> Uplinkrouter jedes mal alles berechnen zu müssen, macht man das in
> meinen Vorschlag 1x und nach weiteren 5 Minuten hat man für den Router
> ja die Koordinaten-Hood-Zuordnung im Cache und muss dann nicht mehr
> berechnen sondern bekommt die Daten direkt aus dem Cache.
>
>
> Das neue Problem wäre, dass man manuell eingreifen muss.
>
>
> Wie oben bereits gesagt, wenn sich an den Hoods was ändert, muss man das
> so oder so manuell machen (Hood anlegen, verschieben, löschen, etc.).
> Der eine Klick mehr tut in meinen Augen nicht weh (ich weiß wovon ich
> rede, was man alles tun muss wenn man eine Hood anlegt, ich hab das
> jetzt doch schon ein paar mal gemacht ;) Von daher glaub mir, den Cache
> danach zu leeren ist firlefanz im Gegensatz zu den Rest).
>
>
> Wenn
> man die Zeit im Cache optimiert, muss man überhaupt nichts
> machen und
> gleichzeitig veraltet auch nichts oder die Datenbank wird immer
> voller.
>
>
> Man hat u.U. 4h lang (oder so lang wie du den Cache aufbewarst)
> inkonsistente Daten (zwischen Routern die sich frisch melden und die,
> die es bereits im Cache gibt), ich kann mir gerade nicht vorstellen was
> da passieren könnte, finde das aber nicht schön. Wenn man nach Änderung
> einfach nur den Cache leert, sind die Daten direkt wieder konsistent da
> alles frisch aufgebaut wird und der Cache leer ist.
> Zudem spart es noch mehr Rechenzeit da nicht alle 4h die Berechnung
> durchgeführt werden muss sondern nur alle paar Tage bis Wochen, je
> nachdem wie oft man neu neue Hood anlegt/löscht/verschiebtm
>
> Man braucht für so einen Cache auch nicht unbedingt eine
> Datenbank, geht
> im Filesystem oder Speicher genau so einfach zu implementieren.
>
>
> stimmt, in PHP (womit ja der keyxchange geschrieben ist) ist ne mysql
> Datenbank aber das bequemste und für ne einzelne Abfrage alle 5 Minuten
> pro Router auch locker schnell genug.
>
> mfg
>
> Christian
>
>
> Grüße von Steffen.
>
>
> Am 20.09.2018 um 08:34 schrieb Christian Dresel:
>
> hi
>
> On 20.09.2018 07:59, Steffen Winkler wrote:
>
> Ja Christian,
>
> Genau so habe ich es gemeint. Der Cache ist dazu da, um die
> Berechnungszeit zu verkürzen, um die Last zu reduzieren,
> für sonst
> nichts. Die Berechnung ist ein Service. In der DB
> Tabelle steht lat,
> lon, das Ergebnis Hood und ein timestamp für created.
> Ein Job, z.b alle
> 4 Stunden schaut nach, was älter ist und wirft die weg,
> damit sich die
>
> warum willst du alte Daten nach Zeit X wieder weg werfen?
> Solange sich
> am Hoodsystem gar nichts ändert, sind die Daten im Cache
> immer und für
> ewig gültig.
> Erst wenn man eine Hood verschiebt/neu anlegt/löscht etc.
> dann muss man
> den Cache komplett neu aufbauen (einfach die Cache Tabelle
> leeren und
> mit meinen Prinzip baut er sich dann von selbst wieder auf).
>
> Zur Sicherheit könnte man natürlich 1x pro Woche oder so den
> Cache
> nochmal automatisiert löschen falls doch was schief läuft
> das es sich
> wieder aufräumt, halte ich aber eigentlich für unnötig.
>
> mfg
>
> Christian
>
> Tabelle wieder aufräumt. Dann musst du nur die neue
> Berechnung machen
> und dann ziehen die Router systematisch in die neue Hood
> um oder lösen
> sich von der alten.
>
> Grüße von Steffen
>
> Am 20. September 2018 07:28:52 MESZ schrieb Christian Dresel
> <fff at chrisi01.de>:
>
> Hi Adrian
>
> On 20.09.2018 00:24, mail at adrianschmutzler.de wrote:
>
> Genau das möchte ich vermeiden, dann haben wir
> durch das
> Caching
> noch eine zusätzliche Schicht, die alles
> komplizierter macht.
>
> Da muss man dann wieder prüfen, ob und welche
> Einträge man in
> der Datenbank aktualisieren muss und welche zu
> dem Geo-System
> gehören und welche zu den normalen Hoods. Das
> muss man dann
> umbuchen usw., und irgendwann blickt keiner
> mehr durch, was an
> welcher Stelle passiert.
>
>
>
> ich hätte das ganze etwa so umgesetzt:
>
> Wir legen im keyxchange eine weitere Tabelle an, wo
> wir die
> GeoDaten zu
> jeder Polygon-Hood abspeichern. Jeder GeoDatensatz
> verweist dann zu
> einer HoodID die wir ganz normal in die bereits
> vorhandene Hood
> Tabelle
> speichern.
> Die Hoodtabelle braucht dann noch ein Flag
> PolygonHood oder
> voronoiHood
> so das bei der voronoi Berechnung die PolygonHood
> nicht getestet
> wird.
>
> Das hat auch den Vorteil, das mehrere Polygone auf
> eine Hood
> verweisen
> können (Schnaittach, Simmelsdorf und noch irgendwas
> verweist
> alles auf
> die Hood Schnaittach)
>
> Im Cache würde ich dann "nur" noch lat, lon und HoodID
> abspeichern, der
> Cache muss gar nicht wissen ob es eine voronoi oder
> PolygonHood
> ist, die
> HoodID reicht.
>
> Sobald man 1x irgendwas an irgendeiner Hood ändern,
> muss der Cache
> natürlich komplett geleert werden und wieder frisch
> aufgebaut
> werden.
> Das kann man wunderbar vor, bzw nach den ganzen
> Berechnung
> machen. Bevor
> man mit den Berechnen anfängt, fragt man die
> lat/lon die der Router
> gesendet hat im Cache ab, gibt es die hat man
> direkt die HoodID
> und kann
> die Hood den Router geben. Gibt es die nicht, führt
> man die
> komplette
> Berechnung durch und speichert am Ende in den Cache
> lat, lon und
> HoodID
> ab damit sie für den nächsten durchlauf zur
> Verfügung stehen.
>
> Ja es ist ein zusätzlicher Fehler aber ich seh das
> nicht als
> kritisch
> an, wenn man den Cache leert falls man eine Hood
> anlegt oder ändert
> sollte eigentlich nichts passieren. Aktualisieren
> oder so muss
> man nie
> was, auch ist es egal zu welchen System der Cache
> gehört, nur
> eben den
> Cache komplett leeren (man könnte natürlich auch
> nur den Bereich
> leeren
> um den es sich handelt aber da wäre mir das
> Fehlerrisiko zu
> hoch, 1x den
> Cache komplett neu aufbauen geht schon) wenn man
> was an den
> Hoods ändert.
>
> mfg
>
> Christian
>
>
> Ich habe im Monitoring ein paar solche Stellen,
> weil ich durch
> die Rückwärtskompatibilität in bestimmten
> Situationen viele
> verschiedene "Systeme" parallel abdecken muss.
> Das ist der Tod!
>
> Ich bin daher grundsätzlich gegen ein System am
> KeyXchange, bei
> dem man Daten der Router cachen muss. Beim
> Cachen von
> Hood-Daten
> bin ich noch am überlegen, aber auch da gibt es
> dann ähnliche
> Probleme bei Hoodwechsel etc., wo immer der
> Cache ein
> zusätzliches Problem darstellt.
>
> Wenn das so kompliziert ist, dass es ohne
> Caching nicht geht,
> und wir jetzt ein System haben, dass wunderbar
> blitzschnell
> problemlos funktioniert, dann spricht das nicht
> für das System.
>
> Grüße
>
> Adrian
>
> -----Original Message-----
> From: franken
> [mailto:franken-bounces at freifunk.net] On
> Behalf Of
> fff at mm.franken.de
> Sent: Mittwoch, 19. September 2018 23:45
> To: franken at freifunk.net
> Subject: Re: Hood-Bildung - Gemeindegrenzen
>
> Hallo Fabian,
>
> Zwar sendet jeder Router nur einen
> Koordinatensatz, im
> worst-case
> müssen aber alle n Polygon-Hoods
> geprüft werden, bevor
> ein match
> gefunden wird
>
>
> Wenn man das nicht in "Echtzeit" prüfen
> will (z.B. mit
> PostGIS), könnte man
> einfach mal von allen Routern die
> Koordinate auslesen, für
> jede Koordinate
> prüfen, in welcher Hood der Router liegt,
> und die Zuordnung
> in eine Tabelle
> schreiben.
>
> Dann bräuchte man bei Anfragen nur in der
> Tabelle
> nachschauen.
>
> Das bedeutet, dass man bei jedem neuen
> Router (bzw. bei
> jeder
> Koordinaten-Änderung) auch die Hood neu
> bestimmen und in
> der
> Tabelle
> ergänzen müsste. Dann wäre die Tabelle
> immer bis auf wenige
> Minuten
> aktuell.
>
> Mit herzlichem Gruss,
> Markus
>
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Mehr Informationen über die Mailingliste franken