IPFS - #4 - Public IPFS Gateways

in #deutsch • 7 years ago (edited)

https://i.imgur.com/L0jNFzh.png

Ich möchte einen Verweis auf eine Datei für alle verfügbar machen. Das heißt, du sollst einfach eine HTTP-URL aufrufen können und an die Datei kommen ohne eine eigene IPFS Node.

Da du in diesem Fall aus dem HTTP Kosmos in den IPFS Kosmos wechseln willst, braucht es Instanz dazwischen, die mit beiden Welten kommunizieren kann: ein Gateway.

Der Entschluss ist gefasst, nun drängen sich die Fragen auf:

  • Welche Public IPFS Gateways gibt es überhaupt?
  • Welches soll ich benutzen?

Wenn du weiter liest, nehme ich dich mit auf meine Entdeckungsreise und wir können gemeinsam versuchen diese Fragen zu beantworten.

Frage 1: Welche Public IPFS Gateways gibt es überhaupt?

Dazu habe ich die Ressource gefunden: https://ipfs.github.io/public-gateway-checker/
Bei mir sah das zum Testzeitpunkt so aus:
https://i.imgur.com/Zhvt76m.jpg

Ok super, ich habe neue Gateways kennengelernt. Bisher kannte ich nur ipfs.io.

Wir nehmen uns jetzt einfach alle die Online sind und vergleichen sie.
Dazu habe ich einen Verweis im IPNS erstellt, gegen den wir prüfen. Was IPNS ist könnt ihr hier oder hier nachlesen und wie ich den Link erstellt habe ist in diesem Post beschrieben.

Frage 2: Welchen soll ich benutzen?

Test 1: Antwortzeiten messen

Als ersten Test versuchen wir mal die Datei hinter unserem IPFS Link zu laden.
Dazu habe ich jeden Gateway 3x hintereinander abgefragt und dabei die Zeit gemessen.
Der Befehl dazu:
time curl https://JEWEILIGE_GATEWAY_ADDRESSE/ipns/QmeUET...ER7

Die Daten habe ich verdichtet und so kommt diese Tabelle raus:

Anfrage URLAntwortzeiten 1, 2, 3
https://ipfs.io/ipns/QmeUET...ER71m58.668s, 1m18.315s, 1m1.908s
https://gateway.ipfs.io/ipns/QmeUET...ER70m1.712s, 0m1.905s, 0m1.826s
https://siderus.io/ipns/QmeUET...ER70m37.366s, 0m1.663s, 0m1.922s
https://ipfs.infura.io/ipns/QmeUET...ER70m22.676s, 0m2.107s, 0m2.116s
https://www.eternum.io/ipns/QmeUET...ER70m47.093s, 0m2.015s, 0m1.703s
https://hardbin.com/ipns/QmeUET...ER70m54.465s, 0m21.888s, 0m1.567s
https://ipfs.jes.xxx/ipns/QmeUET...ER70m1.590s, 0m14.685s, 0m1.711s
https://ipfs.wa.hle.rs/ipns/QmeUET...ER70m42.369s, 0m3.035s, 0m2.844s
https://xmine128.tk/ipns/QmeUET...ER70m27.670s, 0m2.595s, 0m1.767s
  • Der erste Messwert ist meistens hoch
    • Vermutlich ist der Response danach gecached.
    • Es sieht so aus, als wäre die Verbindung zum Gateway schnell hergestellt, aber dessen Antwort dauert unterschiedlich lange. Je nachdem, ob der IPNS-Record auf dem Gateway gecached ist oder nicht.

Test 2: Zeitabschnitte messen

Wenn unsere Annahme aus Test 1 richtig ist, dann müssten wir immer schnell eine Verbindung zum Server herstellen können, aber der Server braucht unterschiedlich lang für eine Antwort.
Das testen wir mal:
curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://JEWEILIGE_GATEWAY_ADDRESSE/ipns/QmeUET...ER7

Auch diesmal gilt: 3x jeden Server Anfragen und zusätzlich folgende Zeiten messen:

Im BefehlIn der GrafikBeschreibung
time_connectinitDie Zeit, die wir brauchen, um uns mit dem Server zu verbinden.
time_starttransferstartDie Zeit, die es dauert, bis der Server anfängt uns zu Antworten.
time_total-Die Zeit von Start bis Ende. Von unserer Anfrage bis die Antwort bei uns angekommen ist.

Da das noch komplexer wird, habe ich das mal visualisiert. Dazu das gemessene Minimum (der schnellste Wert) und das gemessene Maximum (der langsamste Wert).
Es gilt: Je kleiner der Balken, umso schneller kam die Antwort. Kleiner ist in dem Fall besser :)

Minimum

Maximum

  • In der Grafik über den Maximalwert fällt auf, dass "ipfs.jes.xxx" und "siderus.io" immer schnell antworten.
    • Unserer Annahme nach müsste erste Aufruf aber immer länger dauern.
    • Das würde bedeuten, es sind schnelle Cache-Ergebnisse.
    • Wie kann es dann sein, dass die 2 auch initial so flott antworten?

Test 3: Wir prüfen die Server

Dazu lösen wir auf welche Server hinter den Domains liegen:

DomainServer-IP(s)StandortBemerkung
ipfs.io217.182.195.23 147.135.130.181FR (OVH SAS)
gateway.ipfs.io217.182.195.23 147.135.130.181FR (OVH SAS)Das war naheliegend :)
siderus.io104.27.158.37 104.27.159.37Cloudflarevermutlich 104.198.14.52 USA (Google Cloud, CA)
ipfs.infura.io34.192.181.130Amazon EC2
www.eternum.io104.31.66.146 104.31.67.146CloudflareKonnte keine Infos zu dahinter liegenden Servern finden.
hardbin.com178.62.243.230NL (DigitalOcean Amsterdam)
ipfs.jes.xxx178.62.243.230NL (DigitalOcean Amsterdam)
ipfs.wa.hle.rs165.227.15.228US (DigitalOcean, LLC, NY)
xmine128.tk94.199.213.140DE (VCServer Network oHG)

ipfs.jes.xxx und hardbin.com zeigen auf den selben Server. Damit ist klar, warum ipfs.jes.xxx in der Grafik so gut abschneidet. Ich hatte ja direkt vorher hardbin.com getestet und somit ist das Ergebnis vermutlich im Cache.

Nun bleibt die Frage: Was ist mit siderus.io? Warum ist der so schnell?

  • Es könnte sein, dass er letztendlich auch nur auf einen anderen Server verweist, den ich vorher schon getestet hatte. Dazu kann ich nichts eindeutiges herausfinden.
  • Oder er ist wirklich, selbst bei einer ungecachten Anfrage, so flott.
  • Oder er hält den Cache noch seit unserer allerersten Anfrage von Test 1 vor.
  • Oder etwas, was mir noch nicht einfällt :)

Schauen wir mal weiter in die Richtung!

Ich mach meine Abfrage einfach 1h später nochmal:

curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://siderus.io/ipns/QmeUET...ER7
0.090:0.882:0.907

Rennt immer noch. Angeblich wird der Wert für 24h gecached. Ich weiß nicht, ob das stimmt. Ich habe gesehen, dass ich beim "publish" eine TTL mitgeben könnte. Wie ich hinterher die TTL auslese für ein IPNS Record weiß ich leider (noch) nicht.

Gut, anderer Ansatz:
Wir adden einfach eine neue Datei ins IPFS und erneuern unseren IPNS Record. Danach prüfen wir, ob uns der Server wirklich die neue Datei liefert oder noch mit einem alten Cache-Hit antwortet.

Test 4: IPNS Record Update prüfen

added QmSe4g...FxfqG
ipfs name publish QmSe4g...FxfqG
Published to QmeUET...ER7: /ipfs/QmSe4g...FxfqG

Also Link auf neue Datei steht. Wir machen die Abfrage auf den IPNS Record über siderus.io:

curl -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://siderus.io/ipns/QmeUET...ER7
0.085:0.709:0.754

Das ging sehr flott, aber meine Änderung ist nicht drin. Das heißt, wir haben die veraltete Datei erhalten (vermutlich Cache-Treffer).

Gegentest - Wir prüfen bei gateway.ipfs.io:

curl -s -w %{time_connect}:%{time_starttransfer}:%{time_total} https://gateway.ipfs.io/ipns/QmeUET...ER7
0.287:73.130:74.435

Das dauert eine halbe Ewigkeit (über 1 Minute), aber dafür haben wir die neue Datei erhalten. Meine Änderung ist drin.

Daraus kann ich nur schlussfolgern, dass die Gateway-Server unterschiedlich cachen.

Was mache ich nun mit der Info? Soll ich einen schnell antwortenden Server nehmen, der vermutlich 1 Tag lang ein veraltetes Ergebnis ausliefert oder einen Server der für so gut wie jeden Anfrage eine Minute braucht?
https://i.imgur.com/8VrYWge.pngDie hier gezeigten Daten sind keine Bewertung der IPFS Gateways. Es handelt sich nur um eine Stichprobenanlayse zu einem bestimmten Zeitpunkt.

Fazit

Ich weiß noch nicht, wie ich meine Datei publizieren soll. Ich bin voller Begeisterung gestartet und dachte mir: Wenn du jetzt schon den Feed in der Steem Blockchain veröffentlichst, dann nutzt du natürlich auch das dazugehörige dezentrale System.
Die Schwierigkeit kam auf, da ein Gateway überhaupt benötigt wird. Wünschenswert wäre ein Client der direkt IPFS kann, aber das ist kurzfristig unrealistisch. Also kann ich entweder meine coole Datei in der alten Welt einfach schnell jedem verfügbar machen und alles geht simpel und performant oder ich benutze eine Krücke (IPFS Gateway), die eine Verbindung zwischen dem alten bekannten HTTP basierten Web und dem IPFS permanent Web herstellt.

Vermutlich werde ich den Weg mit der Krücke wählen. Auch wenn es noch nicht so gut funktioniert, ist das der einzige Weg den Fortschritt voran zu bringen und zu testen.

Ich freue mich auf euer Feedback und eure Tipps!

#de-stem #ipfs #heutegelernt #ipfsgateway
7 years ago in #deutsch by
$10.74
  • Past Payouts $10.74
  • - Author $8.18
  • - Curators $2.56
87 votes
Reply 10
Sort:  
  • Trending
    • [-]
     7 years ago (edited) 

    Am Ende des Posts wusste ich auch nicht mehr genau was du am Anfang machen wolltest, vielleicht solltest du das im Fazit nochmal erwähnen :)

    Zu dem ganzen Inhalt des Posts. Ich kannte die Abfragemöglichkeit der IPFS Gateways ebenfalls nicht. Interessant wie die Server reagieren und wie unterschiedlich da die Einstellungen zu sein scheinen.
    Eine Desktop App, die damit umgehen kann, wäre wirklich von Vorteil. Für meinen Content wäre es einfach wichtig, dass dieser persistiert : /
    Leider scheint Persistenz der Daten kein wirkliches Anliegen des IPFS zu sein. Was bei den Datenmengen ja nicht ohne Grund extrem Speicher- und Aufwandsintensiv ist. Am Besten wäre es sicher sich einen Server zu mieten, der eine eigene Internetverbindung hat und dort alles regeln kann.
    Wenn du etwas über den Zugriff des Servers auf eine extern liegende Datei und das Umwandeln in Blöcke über externe Verbindung herausfinden könntest, wäre das super :p

    $1.03
    • Past Payouts $1.03
    • - Author $0.78
    • - Curators $0.25
    2 votes
    Reply
    [-]
     7 years ago  

    Danke für das Feedback :) Ich habe am Ende noch mal rein geschrieben, was ich eigentlich machen wollte.

    $0.03
    • Past Payouts $0.03
    • - Author $0.02
    • - Curators $0.00
    1 vote
    Reply
    [-]
     7 years ago  

    This is a test comment, notify @kryzsec on discord if there are any errors please.


    GuidelinesProject Update

    Being A SteemStem Member

    $0.87
    • Past Payouts $0.87
    • - Author $0.66
    • - Curators $0.21
    1 vote
    Reply
    [-]
     7 years ago  

    Die Schwierigkeit kam auf, da ein Gateway überhaupt benötigt wird. Wünschenswert wäre ein Client der direkt IPFS kann, aber das ist kurzfristig unrealistisch.

    Da warte ich auch sehr gespannt drauf! Vielleicht gar nicht so unrealistisch. Die neueste Firefox beta hat das ipfs:// jetzt hook-bar für Erweiterungen gemacht.Quelle Jetzt muss also nur noch jemand hingehen und einen IPFS Node als Firefox Erweiterung zu implementieren. :D

    [-]
     7 years ago  

    Einen IPFS Node auf jeden einzelnen Rechner halte ich für übertrieben.
    Was meiner Meinung nach besser ist, wenn es ein oder zwei Nodes mit Gateway im LAN gibt, beispielsweise auf einem Raspberry Pi, der auch gleichzeitig andere Server-Aufgaben übernehmen kann. Dadurch wird viel Festplattenspeicher gespart, da nicht jeder im LAN z.B. die D.Tube Startseite mit Thumbnails speichern muss. Außerdem ist dieser Ansatz für das IPFS Netz besser, da der Node 24/7 läuft.

    $0.04
    • Past Payouts $0.04
    • - Author $0.03
    • - Curators $0.00
    3 votes
    Reply
    [-]
     7 years ago  

    Ich gebe dir recht, dass ein/zwei Nodes pro LAN reichen und besser sind, wenn sie 24/7 laufen. Aber wenn man sich mal die Ziele von IPFS ansieht (also eine neue Layer unter dem ganzen Internet bereitzustellen), dann muss man es dem Ottonormalverbaucher so einfach wie möglich machen. (Also auf lange Zeit im Browser-Kern und nicht mehr als Erweiterung.) Denn wenn der Ottonormalverbraucher nicht mitmacht, dann wird es immer eine Nische bleiben, was letzten Endes zum Tod des Projekts führen würde.

    Und der aktuelle Ansatz (alle gehen über einen der Hand voll public Gateways) ist halt mist, denn der hebelt im Grunde die ganze Idee des distributed net aus. Ja, man kann sich auch hier wieder eine Erweiterung installieren, die das automatisch umbiegt, aber dann braucht man halt auch wieder eine Node im LAN oder sonst wie lokal am laufen. Was auch wieder den Ottonormalverbraucher abschreckt.

    Es würde mich auch nicht wundern, wenn die Implementierungen der Erweiterungen die Requests dann auf einen beliebigen Gateway leiten können, anstatt selbst einen bereitzustellen.

    [-]
     7 years ago  

    Dass sich immer nur das durchsetzt, was Otto bedienen kann ist leider die Regel.
    IPFS ohne Http ist erst möglich, wenn überall, vor allem auch auf mobilen Geräten Nodes laufen und es auch passende Clients gibt.

    Für eine schnelle Verbreitung wäre es am besten, wenn Router den Node installiert hätten und bekannt machen würden, wie ein lokaler DNS Server über DHCP.

    $0.00
      Reply
      [-]
       7 years ago  

      Moinsen,

      vielen Dank für den Verweis auf den Gateway-Checker. Den kannte ich noch nicht 😁
      Was mich interessieren würde ist, ob du bei deinen Recherchen auf ein deutsches Gateway gestoßen bist. Ich selbst habe (leider) noch keines gefunden...

      Ich weiß noch nicht, wie ich es mache. Ich bin voller Begeisterung gestartet und dachte mir: Wenn du jetzt schon den Feed in der Steem Blockchain veröffentlichst, dann nutzt du natürlich auch das dazugehörige dezentrale System.

      Meinst du z.B. Bilder o.ä. über IPFS reinstellen? Das läuft leider nicht, weil Steemit/Busy die Bilder automatisch cachen 😒
      Wollte das ganze bei meinem zweiten IPFS-Post auch so machen, läuft aber nicht, solange das nicht geändert wird.

      BB,
      JanSe

      $0.02
      • Past Payouts $0.02
      • - Author $0.02
      • - Curators $0.00
      2 votes
      Reply
      [-]
       7 years ago  

      Hallo Janse,

      der letzte Server in meiner Tabelle ist ein deutsches Gateway:
      xmine128.tk 94.199.213.140 DE (VCServer Network oHG)

      Ich möchte eine .xml Datei anbieten. Genau gesagt einen Podcast Feed. Der ändert sich natürlich immer mal, aber die Nutzer brauchen eine konstante Adresse.

      $0.03
      • Past Payouts $0.03
      • - Author $0.03
      • - Curators $0.00
      2 votes
      Reply
      [-]
       7 years ago  

      Hi,

      könnte man, wenn man sich schon irgendwo einen Server mit ipfs-Support holt, nicht auch gleich einen seiner Subdomains per DNS als Gateway bereitstellen?

      Weiß jemand wie man das bewerkstelligt und kennt jemand preiswerte, wenn nicht gar billger IPFS-Provider?

      Gruß
      TheKao

      PS: Wäre schon, wenn Du mal einen Post über die Streaming-Fähigkeit von IPFS machen könntest.

      $0.00
        Reply