Hood-Bildung - SSIDs

Adrian Schmutzler mail at adrianschmutzler.de
Do Sep 20 12:22:41 CEST 2018


Hallo Sebastian,

 

auch wenn es schon viele festgestellt und auch begründet haben, du hattest ja gefragt:

 

Ich möchte das von vornherein nicht.

 

Die SSID soll sich jeder selbst ausdenken. Um Werbung für Freifunk Franken zu machen, mache ich vor Ort Aufkleber, Flyer, Aufsteller oder sonstwas hin.

 

Da steht dann auch keine SSID drauf, sondern „Freifunk Franken“. Da darf dann jeder googlen.

 

Grüße

 

Adrian

 

From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Sebastian Beck
Sent: Donnerstag, 20. September 2018 09:43
To: Freifunk Franken <franken at freifunk.net>
Subject: Re: Hood-Bildung - SSIDs

 

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 <mailto: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 <mailto:fff at chrisi01.de> >:

      Hi Adrian

      On 20.09.2018 00:24, mail at adrianschmutzler.de <mailto: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 <mailto:fff at mm.franken.de> 
              Sent: Mittwoch, 19. September 2018 23:45
              To: franken at freifunk.net <mailto: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.

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20180920/3ac74fe1/attachment.html>


Mehr Informationen über die Mailingliste franken