Das Six/Four System
Eine dezentralisierte anonyme Peer-To-Peer Netzwerk Infrastruktur mit Vertrauen

Entwickler FAQ

Q: Wie kann ich meine eigenen Six/Four basierenden Programme schreiben?

A: Du kannst jede Applikation dazu bringen, dass Six/Four System im Hintergrund zu benutzen und wohin auch immer anonym und verschluesselt zu verbinden.
Hierfuer kannst du ganz einfach die 64 API in ApplicationLayer/API benutzen:

1) Tippe 'make install'
2) Setze -L/usr/local/lib -l64 in deinen Link Optionen
3) Setze -I/usr/local/include/64 in deinen Kompilier Optionen
4) #include "64API.h" im Quellcode mit den 6/4 Aufrufen
5) Rufe API64_init(cert,config,minlinks,tp) in deiner main Funktion auf.
Das initialisiert alle Client und Server Routing Threads und liest die Konfigurations und Hostdateien sowie die TrustedPeer Schluessel.

- cert ist ein vollstaendiger oder relativer Pfad zu einer Datei die ein x509 ssl Zertifikat beinhaltet.
Siehe LinkLayer/SSLkey.sh
- config ist ein vollstaendiger oder relativer Pfad zu einer Konfigurationsdatei.
Siehe CONFIG/64.cfg und und 64hosts.lst fuer ein Beispiel.
Bemerkung: Die Konfigurationsdatei muss immer vom User erstellt werden.
- minlinks ist die Anzahl an Peers die automatisch verlinkt werden sollen.
- tp ist eine "Node *" Struktur (siehe PeerLayer/Node.h) mit wenigstens folgenden gesetzten Variablen: "addr", "port",
"version" und "rsa".
Die RSA Struktur MUSS auf den PublicKey des TrustedPeer verweisen.
Normalerweise wird der PublicKey in einer Datei gespeichert die wie folgt definiert ist und auch so eingelesen wird: TPKEY-<IPADDRESS-OF-TP>

6) Wenn du eine Netzwerkverbindung oeffnen willst benutze nicht den Systemcall connect() -- benutze stattdessen:
API64_connect(client_fd, host, port, data)

- client_fd ist ein File Deskriptor an den eingehende Daten automatisch ueber einen Subthread geschrieben werden.
(Die API hat keinen manuellen read() Aufruf).
- host ist der Hostname.
Benutze ein FQDN, loese ihn nicht selbst auf!
Auf diesem Weg koenntest du zurueckverfolgt werden indem man schaut welche Hostnamen du aufloest.
- port ist die Portnummer, zum Beispiel 80.
Wenn du mehr exotische Ports verwenden willst kann es sein das viel TrustedPeers das nicht zulassen.
- data sind zusaetzliche Daten die sofort an den Server uebermittelt werden sollen.
Kann NULL sein.
- RETURN VALUE API64_connect liefert als Rueckgabewert die SessionID der Verbindung, die zuvor initialisiert wurde.
Fuer weitere Aufrufe MUSS sie gespeichert werden.

7) Gelesen wird automatisch, aber wenn du etwas an den Server schreiben willst benutze API64_write(sid, buf, len).
sid ist die SessionID die gerade erwaehnt wurde, und buf und len sind selbsterklaerend, wie beim normalen write().

8) Wenn du eine Verbindung beenden willst kannst du API64_close(sid, client_fd) verwenden.
Dies schliesst auch automatisch den Client File Deskriptor.
WICHTIG: Six/Four informiert dich nicht immer automatisch wenn eine Verbindung stirbt, abgeschossen wird oder wenn der TrustedPeer sie nicht etablieren kann oder will.
Du musst das selbst sehen indem du einfach timeouts setzt und ggf. erneut versuchst die Verbindung herzustellen.

Der Client SessionID Thread hat einen maximalen Timeout der von einem anderen Thread permanent ueberprueft wird.
Gesetzt ist er in DL_TIMEOUT in der Datei PeerLayer/CLIENT/Download.h.
Gegebenenfalls kannst du ihn niedriger setzen (oder auch nicht).

Das ist alles! Das (zusammen mit dem Format der Konfigurationsdatei) ist fast alles was du wissen musst um deine eigenen Six/Four Programme zu schreiben.

Q: Auch wenn ich es nicht wissen muss, wie funktioniert das lower-level Peer Layer?

A: Um Verbindungen herzustellen wird eine Six/Four Session aufgebaut die das eigentliche Ziel ueber einen TrustedPeer tunnelt, indem es den StartSession call benutzt:

DOWNLOAD->StartSession(TrustedPeer,
InitialData,
Datalen,
"host.com",
123,
destfd);

Eingehende Daten werden direkt auf destfd geschrieben.
StartSession liefert eine Transfer ID Nummer (TID) zurueck.
Um weitere Daten zu senden benutze hierfuer DOWNLOAD->SendCliData(TID, buffer, buflen);

Das ist alles.
Jetzt brauchst du nur noch eine Art Backend in deinem Programm um das Six/Four Protokoll zu benutzen.
Die beste Art dies umzusetzen sind 2-3 Threads.
Benutze einen ACCEPT Thread der erst LINKLAYER->listen() und dann regelmaessig LINKLAYER->accept() aufruft.
Der Rueckgabewert von accept() wird innerhalb des LINKLAYER Objekts geparsed.
Der andere Thread ist ein DATA INPUT Thread.
Hier musst du LINKLAYER->select() aufrufen, was einige Link Objekte zurueckliefern wird.
Fuer jedes Objekt solltest du die Methode Link->read() benutzen um Daten in einen Buffer zu lesen und diesen dann an CLEVER->route() zu uebergeben -- das ist alles der grundlegenden Funktionsweise.
Zwei weitere Funktionen die in regelmaessigen Abstaenden aufgerufen werden sollten -- in Threads oder wo auch immer - sind
MaintainMinCon() aus stdfunc.cpp und DOWNLOAD->Timeout().
Das ist alles was du jemals in deinen Programm implementieren musst, damit sie mit dem Six/Four Protokoll laufen.

Q: Kann ich in beide Richtungen senden und kann ich eine realtime 2-Wege Unterhaltung haben?

A: Natuerlich! Lass dich nicht von den Namen "Upload" und "Download" verwirren.
Upload ist fuer das bereitstellen einer Verbindung als TrustedPeer und Download hat die Funktion die jeder normale Clerver
aufruft um eine Verbindung ueber einen TP herzustellen und in realtime zu kommunizieren.

Um irgendwohin eine Verbindung zu erstellen benutze einfach StartSession() um eine Anfrage an einen TrustedPeer zu stellen.
Sobald GotData() aufgerufen wird werden die Daten zurueck an den File Deskriptor geschickt, den du in StartSession() angegeben hast.
Das kann unter anderen eine Datei, der Standard Input, ein Socket oder eine Pipe sein.

Du erhaelst die Daten vom Server automatisch.
Um Daten an den Server zu schicken rufe einfach jedesmal SendCliData() auf.
Du musst fuer all diese Aufrufe lediglich die TID angeben.

Q: Was gibt es fuer Nachrichten Typen?

A: Du brauchst dich darum nicht kuemmern, nur mit der API in Clerver, Download, LinkLayer (und vielleicht Discovery)

Im Moment gibt es PING/PONG (zum Finden von Nodes), STARTR (um eine TCP Verbindung ueber einen TP zu initialisieren), START_UDP (um dasselbe mit UDP zu tun), CLIR (um weitere Daten zu einer Verbindung zu schicken), ACK (um ACKs als Antwort fuer erhaltene Daten zu senden), DATA (Daten vom Server an uns) und DONE (von einer der beiden Parteien gesendet um die
Verbindung entgueltig zu beenden).

Q: Wie funktioniert das Routing?

A: Das Routing ist anonym sofern es ueber 3 oder mehr Clerver geht -- das heisst das kein Clerver Informationen darueber hat, welche Peers das Packet das er gerade routet noch senden werden beziehungsweise gesendet haben.
Jeder Clerver kennt lediglich die RoutingID, den direkten Quell- und den Zielnachbar.
Die Routing Topologie ist Gnutella, jeder Clever verbindet sich mit einer beliebigen Anzahl an Nachbarn, von Einem bis einem Dutzend, und schickt seine ausgehenden Paket an zufaellige dieser Peers.
Pakete laufen nach Hops ab und Duplikate werden durch gemeinsame Routing IDs verhindert.

Q: Das Routing stinkt, ich will multiskalierbares, multi-mega-hypercube Routing!

A: Das Ziel dieses Protokolls ist es, es so einfach wie moeglich anwendbar zu machen und dabei die Effizienz zu erhalten.
Wenn du dir die Gnutella Topologie anschaust wirst du sehen, dort gibt es keine Regeln.
Viele Entwickler von Gnutella haben Anwendungen herausgebracht, die eine eigene Topography enthalten, ohne dabei die
Gnutella Protokoll Standards zu brechen (wie zum Beispiel MorpheusPE oder BearShare oder LimeWire).
Sie benutzen lediglich Tricks um wesentlich effizienter zu laufen das das eigentliche Gnutella Protokoll.
Du kannst der erste sein, der dies mit dem Six/Four Protokoll macht!
Es ist auch jeden Fall moeglich, tue es einfach!

Q: Wie funktioniert die Verschluesselung?

A: Node-zu-Node Verschluesselung ist traditionelles SSL.
Der Standardport ist 443 um es wie HTTPS Daten aussehen zu lassen.
End-to-End (TrustedPeer) RSA-basierende Verschluesselung ist __mandatory__ und heisst das:

1) Node Benutzer muessen den Key jedes TrustedPeer erhalten und verifizieren (entweder Out-of-Band oder ueber bereits bekannte Peers)

2) Sobald eine Verbindungsanfrage gestellt wird senden die End-Nodes ihren Session-Key an den TrustedPeer.
Das Initialisierungspacket an den TP wird RSA verschluesselt, der Rest der Kommunikation wird jedoch mit dem SessionKey verschluesselt.
Der preauthentifizierte RSA Schluessel versichert Authentizitaet und schuetzt damit vor Man-In-The-Middle Attacken.

INDEX