text: forum.yacy.de • Thema anzeigen - Seed-List defekt
  Seed-List defekt
  von Erik_S » Fr Okt 17, 2014 3:46 pm
  mir sind gerade Fehlermeldungen meines Analyse-Tools aufgefallen das die Anführungszeichen bei manchen Feldern fehlen und ein manuelles nachschauen hat ergeben das dem tatsächlich so ist.
  Bei mehreren Peers mit Version 1.81009106 sind die Felder "Hash" und "Address" bei allen Peers in der Seed-Liste defekt.
  "Hash":0000000000,
  "Address":["0.0.0.0:8090"]
  (die 0en hab ich geändert, der eigentliche Inhalt der Felder ist korrekt nur die Syntax ist defekt)
  Wie die anderen Peers darauf reagieren weiß ich natürlich nicht aber für mein Tool sind die betreffenden Peers nicht mehr online da sie auch sich selbst (im ersten Eintrag der Seed-Liste) nicht mehr korrekt melden.
  Alle anderen Felder sind korrekt. Meiner Meinung nach kann das Feld "Address" komplett entfallen aber das Feld "Hash" muss in jeden Fall repariert werden.
  Und wenn eh gerade was geändert wird, ich möchte noch einmal darum Bitten bei den IPv6-Adressen die Interface-Identifier zu entfernen.
  In der Seed-Liste die ich gerade manuell durchgesehen hab war aber auch ein Peer dabei der eine IPv4-Adresse im Feld "IP6" und eine IPv6-Adresse (mit Interface-Identifier) im Feld "IP" hat (und beides im Feld "Address" ganz komisch zusammen aber dafür ohne Interface-Identifier).
  Re: Seed-List defekt
  von Orbiter » Fr Okt 17, 2014 8:36 pm
  ups die hashes waren kaputt, habs gerade gefixt. Das Address-Feld sollte ok sein, das ist nun eine Liste.
  Ich weiss dass du das Feld nicht willst, aber ich habe es im XML hinzu genommen weil man das schön grepen kann zur Weiterverarbeitung, im JSON ist es nur aus symmetrie drin. Solange es nicht technisch stört würde ich es gerne drin behalten, auch wenn die Information Redundanz hat.
  von Erik_S » Sa Okt 18, 2014 7:50 am
  Orbiter hat geschrieben: habs gerade gefixt.
  Ja, ist wieder okay.
  Orbiter hat geschrieben: Das Address-Feld sollte ok sein, das ist nun eine Liste.
  Naja, Du zerstörst damit die allgemeine Syntax der Liste. Ich würde folgendes bevorzugen:
  "Address":"0.0.0.0:8090|[2003::3002]:8090",
  Die Pipe als Trenner in der Liste ist okay (so wie im Feld "IP6") da sie weder in IPv4-Socket-Adressen noch in IPv6-Socket-Adressen vorkommt. Die eckigen klammern als Umschließendes Element empfinde ich als kritisch da diese in den IPv6-Adressen ebenfalls vorkommen.
  Das aus meiner Sicht kritischste Problem ist aber das es plötzlich ein einzelnes Feld gibt das die Anführungszeichen nicht mehr als komplett umschließendes Element für Feld-Name und Feld-Inhalt hat, das zerstört die Gesamtsyntax.
  Ob ich persönlich das Feld "Address" mag oder nicht spielt doch keine Rolle, mein Tool ignoriert dieses Feld einfach, wichtig ist primär das der Basis-Parser für alle Felder einheitlich bleiben kann.
  von Orbiter » Sa Okt 18, 2014 10:37 am
  Das ist valides json, so wie es ist, nicht 'kritisch' weil da eckige Klammern sind, weiss nicht warum ich da einen pipe nehmen soll. Dann müsste man das ja wieder extra parsen.
  von Erik_S » Sa Okt 18, 2014 11:06 am
  das Basis-Format war bisher
  "Field-Name":"Field-Value"
  (also die Anführungszeichen haben sowohl den kompletten Namen umschlossen als auch den kompletten Content) und daran hast Du etwas geändert.
  Warum führst Du für eine weitere Aufzählung ein neues Format ein? In "IP6" ist doch bereits eine Aufzählung mit einem Format das sich mit der bisherigen Basis gut verträgt.
  Ich verstehe Deine Design-Entscheidung einfach nicht, meiner persönlichen Meinung nach ist diese Design-Entscheidung ein "Symetriebruch" (für den es keinen Grund gibt).
  Kommen mit dem neuen Format eigentlich die alten Peers noch zurecht?
  Ich beobachte auf jeden Fall das die erreichbaren Peers derzeit weniger "online"-Peers kennen als gestern.
  von Erik_S » Sa Okt 18, 2014 1:27 pm
  ich hab mir gerade die neue Dokumentation unter http://www.yacy-websuche.de/wiki/index.php/Dev:APIseedlist angesehen und ich verstehe einfach nicht warum Du für ein und das selbe Problem "Aufzählung" zwei verschiedene Lösungen benutzt (sowohl im JSON-Format als auch im XML-Format). Im Feld "IP6" hast Du das Pipe-Zeichen als Trenner für die Aufzählung benutzt (in beiden Formaten) wogegen das Feld "Address" entweder mehrfach vorkommt (XML) oder eine neue/problematische Syntax benutzt (JSON). Ich verstehe nicht warum für das Feld "Address" eine neue Lösung benutzt wird obwohl die vorhandene Lösung (vom Feld "IP6") doch problemlos funktionieren würde. Aus meiner Sicht ist das unnötige Komplexität. Da jede Komplexität grundsätzlich immer das Risiko von Fehlern birgt und man doch eigentlich bemüht ist Fehler möglichst zu vermeiden sollte man doch auch versuchen Komplexität möglichst zu vermeiden, vor allem wenn sie unnötig ist.
  Ich weiß das Du mir keinerlei Rechenschaft schuldig bist aber ich möchte Deine Design-Entscheidung einfach gerne verstehen.
  von Erik_S » Sa Okt 18, 2014 6:49 pm
  wäre es denn ein akzeptabler Kompromiss das Feld "Address" in der JSON-Liste mehrfach vorkommen zu lassen, so wie in XML?
  Das würde mir zumindest ersparen einen neuen Parser bauen zu müssen.
  Zeichen die sowohl Struktur als auch Inhalt sein können sind einfach keine gute Idee, nicht umsonst ist sowas bei XML verboten.
  Ich weiß ja nicht in welchem Format die Peers normalerweise untereinander ihre Seed-Listen austauschen aber in den Seed-Listen von Peers mit Versionen vor 1.81009106 sind im Feld "Address" immer nur eine einzelne Socket-Adresse enthalten (und keine eckigen Klammern), auch für neuere Peers. Bist Du sicher das der Austausch der Seed-Listen zwischen alten und neuen Peers noch korrekt/vollständig funktioniert?
  von Orbiter » So Okt 19, 2014 8:25 pm
  das p2p Bootstraping nutzt das Servlet gar nicht, das hier ist 'future use'.
  Beim XML sind Mehrfachnennungen valide, bei JSON nicht, weil das eine Map ist die im DOM von JSON so nicht Mehrfachnennungen vorsieht.
  Zum Thema 'valides JSON' empfehle ich die EBNF lt. http://json.org/ , da kann man auch Parser runterladen. Ich habe die Validität von des JSON überpfüft, u.a. mit http://jsonlint.com/. Das ist so in ordnung. Andere Darstellungsformen sind nicht sinnvoll weil man das dann innerhalb von Javascript nicht verwenden könnte. Bitte nicht mit 'dann muss ich aber meine Parser umschreiben' argumentieren, hier gilt die offizielle Spezifikation lt. json.org
  von Erik_S » Mo Okt 20, 2014 12:01 pm
  ich habe doch gar nicht bezweifelt dass das Format noch immer der JSON-Spezifikation entspricht, was mich stört ist das Du den verwendeten Teil der JSON-Spezifikation deutlich vergrößert hast und das ohne erkennbare Notwendigkeit.
  Ich verstehe noch immer nicht was an der Aufzählung/Liste im Feld "Address" so anders ist als an der Aufzählung/Liste im Feld "IP6". Warum kann man nicht für beide Felder ein einheitliches Format benutzen? Innerhalb der jeweiligen Möglichkeiten von JSON bzw. XML natürlich.
  Die Parser die man von json.org runterladen kann sind viel zu groß und viel zu aufwendig. Die meisten nutzen z.B. malloc um aus den Daten erstmal einen DOM-Baum zu bauen aber ich will doch einfach nur den Inhalt der Felder um diesen in eigene Datenstrukturen zu übertragen und dabei die JSON-Daten nur als vorbeifliegenden Datenstrom verarbeiten. Da ich zur Beurteilung der Reaktionsgeschwindigkeit der Peers die Übertragungszeit messe aber die empfangenen Daten nirgends speichere sondern in Echtzeit verarbeite ist da auch immer die von meinem Tool benötigte CPU-Zeit mit drin und deswegen muss der Parser möglichst effizient sein damit die CPU die empfangenen Daten schneller verarbeiten kann als sie per Internet kommen, mit meiner derzeitigen Implementierung (egal ob XML oder JSON) schafft das selbst der 12 Jahre alte 1.6GHz PentiumM in meinem Entwicklungsrechner problemlos.
  Ich habe mein Tool gestern auf XML umgestellt, die XML-Spezifikation ist meines Wissens nach deutlich strenger und das kommt mir in meinem Vorhaben einen möglichst simplen und effizienten Parser zu bauen deutlich entgegen.
  Leider hat sich damit die Situation nicht verbessert da viele Peers (mit verschiedenen aber meist älteren Versionen) mit einer leeren HTTP-Response für "/yacy/seedlist.xml" antworten. Es kommt als Antwort nur ein gültiger HTTP-Response-Header mit Code 200 aber dann gar keine Daten, ich habe das sowohl mit nem Browser als auch mit wget nachgestellt und mit Wireshark geprüft. Kann es sein das da mal ein Bug o.ä. in YaCy war?
  So wie ich das sehe habe ich jetzt 3 Möglichkeiten mein Tool anzupassen damit es wieder alle Peers findet:
  ich implementiere beides also XML und JSON, wobei dann noch zu prüfen wäre welches Format ich als erstes abrufe (damit möglichst wenig Bandbreite verschwendet wird)
  das würde primär dazu führen das ich den Code fürs Parsen und fürs Auswerten der gewonnenen Daten besser trennen muss damit nur der Parser doppelt vorhanden ist (aber das muss ja nichts schlechtes sein schließlich ist "Teile und Herrsche" schon immer beliebt gewesen), ich denke das würde meinen Code um weniger als 200 Zeilen vergrößern und ist in der Hinsicht vermutlich ein guter Kompromiss
  ich könnte bei JSON bleiben und einfach nur das Feld "Address" besser ignorieren, das würde zwar Bandbreite (das XML-Format ist fast doppelt so groß) und etwas CPU-Zeit sparen aber hätte den Nachteil das ich bei zukünftigen Änderungen am Format vermutlich wieder vor dem selben Problem stehe (bei XML bin ich aufgrund der deutlich strengeren Spezifikation vor solchen Überraschungen geschützt)
  ich bleibe einfach bei nur XML und ignoriere die Peers die da Bugs/Probleme haben, mit der Zeit werden die sicher weniger, wobei wenn ich mir ansehe wie die Versionen so verteilt sind dann fürchte ich das es eventuell Jahre dauern könnte bis es keine YaCy-Peers mehr gibt die kein XML liefern
  Mal wirklich ernsthaft, zu welcher der 3 Möglichkeiten würdest Du mir raten? Ich bin da momentan echt unschlüssig.
  Wäre es möglich beim XML-Format die Einrückungen und Zeilenumbrüche wegzulassen? Gerade die Einrückungen mit den vielen Leerzeichen verursachen einen erheblichen Anteil am übertragenen Datenvolumen, es wäre sicher auch für die YaCy-Peers selber von Vorteil hier sparen zu können. XML macht diesbezüglich keinerlei Vorgaben, die Validität bliebe erhalten.
  von Orbiter » Mo Okt 20, 2014 4:59 pm
  das IP6 Feld im Seed trennt die IPs mit einem Pipe weil die zugrunde liegende Datenstruktur für die Seed-DNA eine flache Map ist und intern encodiert als komma-separierte Propery-Liste dargestellt wird, bei dem man eben in den Attributwerten keine Kommas haben darf. Das ist zwar auch nicht optimal aber so ist es halt seit den allerersten Seeds und alle Peers kommunizieren genau das Format. Die Ausgabe in der seedlist repräsentiert einfach nur das was da drin steht. Die 'Flachheit' der DNA war für diesen Zweck wohl etwas zu primitiv und daher ein Konstruktionsfehler, ich will den aber nicht in die Zukunft tragen und Dinge nehmen die Standards entsprechen.
  Die Spaces im XML kann ich weglassen, die CR aber nicht weil man dann das ganze nicht mehr mit grep und sed in einem bash script parsen kann.
  von Erik_S » Di Okt 21, 2014 8:31 pm
  ich habe mich dazu entschlossen mit meinen Tool XML und JSON zu unterstützen, zuerst wird per XML abgefragt und nur falls das nicht funktioniert wird zusätzlich JSON probiert. Da wohl primär ältere Peers Probleme mit XML haben aber diese dafür auch die simple JSON-Syntax benutzen ist momentan die Erkennungsquote in meinem Tool wieder auf altem Niveau, siehe http://130.255.73.69:5353/stats_main.
  Orbiter hat geschrieben: das IP6 Feld im Seed trennt die IPs mit einem Pipe weil die zugrunde liegende Datenstruktur für die Seed-DNA eine flache Map ist und intern encodiert als komma-separierte Propery-Liste dargestellt wird
  Sorry, aber ich verstehe immer noch nicht was der relevante Unterschied zwischen der Aufzählung/Liste im Feld "IP6" und der Aufzählung/Liste im Feld "Address" ist. An neu oder alt kann es doch in beiden Fällen nicht liegen da bis vor kurzem die Felder entweder noch gar nicht existierten oder grundsätzlich nur ein einzelnes Element enthielten.
  Auf jeden Fall habe ich mein Tool so vorbereitet das es das Feld "IP6" mehrfach geben darf, bei XML und JSON. Das Feld "Address" wird von meinem Tool eh ignoriert also merkt es auch nicht ob es mehrfach vorkommt, hauptsache die Basis-Syntax passt.
  Orbiter hat geschrieben: Die Spaces im XML kann ich weglassen
  Das wäre auf jeden Fall eine spürbare Verkleinerung des übertragenen Datenvolumens, Danke. Tools wie grep und sed sind natürlich ein nachvollziehbares Argument. Cool wäre ja wenn es ein Query-Parameter (z.B. "?compact=true") gäbe mit dem bestimmt werden könnte ob der XML-Datensatz kompakt (also ohne alle unnötigen Leerzeichen und Zeilenumbrüche) oder gut verarbeitbar bzw. menschenlesbar sein soll.