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:
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 URL | Antwortzeiten 1, 2, 3 |
|---|---|
 | 1m58.668s, 1m18.315s, 1m1.908s |
 | 0m1.712s, 0m1.905s, 0m1.826s |
 | 0m37.366s, 0m1.663s, 0m1.922s |
 | 0m22.676s, 0m2.107s, 0m2.116s |
 | 0m47.093s, 0m2.015s, 0m1.703s |
 | 0m54.465s, 0m21.888s, 0m1.567s |
 | 0m1.590s, 0m14.685s, 0m1.711s |
 | 0m42.369s, 0m3.035s, 0m2.844s |
 | 0m27.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 Befehl | In der Grafik | Beschreibung |
|---|---|---|
time_connect | init | Die Zeit, die wir brauchen, um uns mit dem Server zu verbinden. |
time_starttransfer | start | Die 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 :)
- 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:
| Domain | Server-IP(s) | Standort | Bemerkung |
|---|---|---|---|
| ipfs.io | 217.182.195.23 147.135.130.181 | FR (OVH SAS) | |
| gateway.ipfs.io | 217.182.195.23 147.135.130.181 | FR (OVH SAS) | Das war naheliegend :) |
| siderus.io | 104.27.158.37 104.27.159.37 | Cloudflare | vermutlich 104.198.14.52 USA (Google Cloud, CA) |
| ipfs.infura.io | 34.192.181.130 | Amazon EC2 | |
| www.eternum.io | 104.31.66.146 104.31.67.146 | Cloudflare | Konnte keine Infos zu dahinter liegenden Servern finden. |
| hardbin.com | 178.62.243.230 | NL (DigitalOcean Amsterdam) | |
| ipfs.jes.xxx | 178.62.243.230 | NL (DigitalOcean Amsterdam) | |
| ipfs.wa.hle.rs | 165.227.15.228 | US (DigitalOcean, LLC, NY) | |
| xmine128.tk | 94.199.213.140 | DE (VCServer Network oHG) |
ipfs.jes.xxxundhardbin.comzeigen auf den selben Server. Damit ist klar, warumipfs.jes.xxxin der Grafik so gut abschneidet. Ich hatte ja direkt vorherhardbin.comgetestet 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?
 | Die 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!