[GenericProtocol] Aufbau

Information: Diese Definition ist noch nicht komplett - Es fehlen noch einige Informationen, die nachgereicht werden!

Ich bin schon seit längerem daran, etwas herum zu experimentieren. Dabei habe ich ich das GenericProtocol aufgeschlüsselt, damit es verständlicher wird, was das ganze überhaupt soll und wie es funktioniert.

Der Grundgedanke dabei war, eine Art Protkoll zu schaffen, was wenig Traffic verursacht, aber auch sogenannte SubNodes, also untergeordnete Komponenten besitzt. Fälschlicher Weise wird das ganze oftmals auch als "Module Protokoll" bezeichnet, da das ganze bisher ein "zusätzliches Modul" gewesen ist - Ich denke mal, dies wird sich mit K3 aber ändern. Das alte ChatServer-Protokoll, was durch NULL-Byte getrennt wird, wird es sicherlich nicht mehr lange geben, zumal schon so einige Komponenten dafür umgestellt worden sind (Nehmen wir das Beispiel der CHANNEL_MEMBERS - Das alte Protokoll mit dem u-Token (UserList) gibt es somit nicht mehr und wurde durch das GenericProtocol ersetzt).

Das ganze ist also nicht nur als einfache Information âla "Wie funktioniert das ganze?" gedacht, sondern sollte auch für zukünftige Bot-Projekte nützlich sein.

Der Aufbau
Meist durch das "Tree" bezeichnet, wird das Protokoll definiert. Hier wird festgesetzt, wie das Protokoll aufgebaut ist und welche "Typen" zu erwarten sind. Jeder Eintrag ist mit einem Semikolon (;) getrennt, Außnahme der Single-PropertieValues(?), die die Tokens nach den TokenRelations mittels einmaligem Doppelpunkt (:) trennt.

Der "Tree" ist wie folgt zusammengesetzt:
<Header><Tokens>;<TokenRelations>:<Unbekannt, Single-PropertieValues?>

Header
P.S. ich hoffe einer der Mods/Admins kann die Tabelle etwas aufhübschen, da mir die ganzen BBCodes dafür nicht bekannt sind.

Index	Type	Example	Description
0	Long	-297292011	Der Hash des "Tree's" - Definiert die Protokoll-Version
1	Long	20	Definiert die Start-Position der Tokens (näheres, siehe unten)

Als Beispiel gibt es folgenden Header:

-297292011;20;

Version / Hash
Der Hash bzw. die Version definiert in einem Long-DatenTyp, um welche Tree-Version es sich handelt. Beim Verbinden wird dieser Wert dafür genutzt, beim ChatServer abzufragen (CONFIRM_PROTOCOL_HASH): "Hey, ich bin es - Der Client! Ich habe Version 1234, ist diese in Ordnung?". Der ChatServer antwortet dann entweder mit einem PROTOCOL_CONFIRMED, weil die aktuelle Tree-Version in Ordnung ist oder übermittelt dem Clienten bei CHANGE_PROTOCOL eine neuere Version.

Start-Position
Dieser Integer-Wert zeigt nur an, ab welcher Position die TokenNames eingefügt werden sollen. Das ganze hat nichts damit zu tun, welche Position die Tokens im "Tree" anfangen, sondern ab wann der Index der "Custom DataTypes" beginnt.

Knuddels hat hierfür bereits feste Indexe, die nicht überschrieben werden sollten, denn diese besagen, um welchen primitiven DatenTyp es sich handelt. Um es einfach zu sagen: Alle TokenNames, die vorkommen sind in dem Sinne ein eigener DatenTyp, die neben den Haupt-DatenTypen wie byte, int, long, short,... existieren. Denn beim "zusammenbasteln" der Daten wird vor dem Datensatz der DatenTyp mit angegeben - Als Beispiel:

Zitat:

---

01 - DatenTyp 0 (byte) mit Value "1"
8a - DatenTyp 8 (char) mit Value "a"
9Hello World! - DatenTyp 9 (UTF-8 String) mit Value "Hello World!"

---

Hier einmal die Standard DatenTypen:

Index	Type
0	byte
1	Boolean
2	byte
3	Short
4	Integer
5	Long
6	Float
7	Double
8	Character
9	String (UTF-8)
10	BinaryTree
11	ArrayList
12	Exception: ArrayEnd
13	String Value

Anhand der Tabelle kann man sehen, dass die DatenTypen 0-13 bereits belegt sind, durch das "Tree" fangen dann die "Custom" DataTypes mit 20 an.
In der Theorie könnten weitere DatenTypen mit dem Start-Index 14 beginnen, aber zwischen 14-20 hat sich Knuddels anscheinend gedacht, dass hier vielleicht noch weitere fest implementierte Typen hin komen...

Tokens
Hier werden die "Custom" DataTypes definiert, beginnend mit dem StartIndex aus dem Header (als Beispiel "20"). Diese sind durch ein Semikolon (;) getrennt und der Index wird hier einfach addiert.

Ein Beispiel ergibt folgende DatenTypen-Tabelle:

PROTOCOL_HASH;CONFIRM_PROTOCOL_HASH;PROTOCOL_CONFIRMED;PROTOCOL_DATA;[...]

Index	Type
20	PROTOCOL_HASH
21	CONFIRM_PROTOCOL_HASH
22	PROTOCOL_CONFIRMED
23	PROTOCOL_DATA
24	[...]

Wird ein Datensatz so "zusammengebastelt", wird auch hier vor dem Datensatz der DatenTyp mit angegeben, nur dass dies keine "primitiven DatenTypen" sind, sondern eigen definierte - Als Beispiel:

Zitat:

---

23-123456;2;TOKEN;TOKEN;TOKEN[...] - DatenTyp 23 (PROTOCOL_DATA) mit Value "-123456;2;TOKEN;TOKEN;TOKEN[...]"
21**** - DatenTyp 21 (CONFIRM_PROTOCOL_HASH) - Zu dem "Value" kommen wir später, denn hier sind nun die Relations wichtig!
20-12345 - DatenTyp 20 (PROTOCOL_HASH) mit Value "-12345" - Eigentlich ist hier in dem Sinne einfach ein Long (also DatenTyp 5) notwendig, der Token wird dennoch als eigener DatenTyp definiert, da dies eine Sub-Value ist - Sprich ein Teil einer Node. Um das einfacher zu erläutern: Stellt euch JSON vor - Hier gibt es "CONFIRM_PROTOCOL_HASH" als Key mit einem unterobjekt, was "PROTOCOL_HASH" enthält.

---

Relations
Wie bereits in dem Abschnitt "DatenTypen" bei den Beispielen gezeigt, gibt es Relations - Also Daten, die zusammen gehören. Diese werden pro Sektion mit einem separatem Semikolon (;) getrennt, um deren "Ende" aufzuzeigen, da eine Node weitere Informationen enthalten kann. Hierzu wird der DatenTyp-Index genutzt.

Der Durchlauf beginnt auch hier wieder mit dem Start-Index "20". Es wird also in folgendem Beispiel der DatenTyp "20" (PROTOCOL_HASH) definiert, welche Relationen dieser besitzt.

Ein Beispiel:

Zitat:

---

5;;20;;;
- - -
| | |
| | |
| | +---- Ende der Definition
| +--------- DatenTyp "20" muss "20" enthalten
+------------- DatenTyp "20" muss "5" enthalten

---

- Dieser Part ist noch unvollständig und wird noch überarbeitet -

Typ 0 ist an sich kein Byte, sondern ein ENUM Value. Es hat nur die größe eines Bytes.

Aufbau des Trees


es wird gesplittet nach dem ersten ;;
Das erste Split sind die
PROTOCOL_NAMES, diese werden mit Semikolon gesplittet und beginnen mit einem Index von 20 (wie oben erklärt, haben wir 20 als offset im header)

Das zweite Split wird dann nochmal getrennt nach einem :

Daraus folgenden die letzten Zwei Blöcke
Der erste Protocol sind die PROTOCOL_STRUCTURES, die sind wieder Semikolon getrennt und geben an, wie die PROTOCOLLE aufgebaut sind

0-13 die oben genannten Typen, über 20 ist dann wieder nur ein neues PROTOCOL_STRUCTURE

Der Zweite Teil sind die ENUM VALUES, die mit ;; voneinander getrennt sind


Geht man die PROTOCOL_STRUCURES alle durch, ist überall wo ein einzelner WERT nur 0 ist, ein ENUM...
In der Reihenfolge kommen dann auch die ENUM_VALUES und man kann dann entsprechend auch die ENUMS den PROTOCOL_NAMES zuweisen.

Was ich derzeit nicht verste, ist ein ganz spezieller Part, an dem die Assignments geschehen - Sprich, die Zuweisungen zu den jeweiligen Typen.
Und zwar ist dies folgende stelle:

Zitat:

---

<Version>;<Offset>;[<Token>;<Token>;<Token>;];<?>;;<?>;;;[<Assignment>;;<Assignment>;;][....]

---

Daraus resultiert folgendes (gekürzt):

Zitat:

---

-736340139;20;PROTOCOL_HASH;CONFIRM_PROTOCOL_HASH;;5;;20;;;9;;23;;13;;

---

Das grüne Semikolon bezeichnet das Ende des ersten Parts, die TokenNames. Diese Struktur kurz danach ist noch ziemlich verwirrend. Warum taucht auf dieser stelle drei mal ein Semikolon auf?
Das ganze passt nicht wirklich zum Schema, da die Zuweisung wie folgt passiert: <Aktueller Index> = <Typ> (Der <Typ> ist das, was dort als Integer steht, sprich 5 = Short oder 20 = PROTOCOL_HASH). Dies wird dann auf einmal durch ein drittes Semikolon verwirrend gemacht.

Entweder kommt der "Leereintrag" von PROTOCOL_CONFIRMED, weil dies eben keine Value besitzt, sondern einfach nur auf existenz abgefragt wird, es zeigt hier ein "Ende" oder ich weiß auch nicht...

Im übrigen werden die Assignments nicht nach ;; gesplitted, dies ist falsch. Es zeigt nur das Ende. Jedes Assigment endet mit einem Semikolon, sind die Assignments für den aktuellen Index definiert, kommt als letztes noch einmal ein Semikolon, um das zu beenden. Denn es gibt nicht nur single-assignments, sondern es können zum <Type> auch mehrere Assignments geschehen.

Beispiel:
Single-Assignment:

Zitat:

---

<ID>;;

---

Multiple-Assignments:

Zitat:

---

<ID>;<ID>;<ID>;<ID>;;

---

die drei semikolon sind ganz klar... das paket hat keinen inhalt

Okay, nach genauem analysieren, funktioniert das wie folgt:

Der Part's eines Assignments gibt wie bereits mir zuvor bekannt die <Types> wieder, die durch Semikolon getrennt werden. Ist etwas nicht deklariert/zugewiesen, erhält dies einen Leereintrag ohne Angaben eines Indexes/Types. Die drei Semikolons haben also keine spezielle Bedeutung und spiegeln nur den Leereintrag wieder. Normale Zuweisungen werden mit zwei Semikolons abgeschlossen, leere Zuweisungen hingegen nur mit einem(!).

Durch das Analysieren konnte ich nun den GenericTree so bauen, dass ich mir ein komplett eigenes Tree erstellen konnte. Bisher auf JavaScript-Basis via ES6 - Einzige Problem hier, dass JavaScript (Node.js verhält sich da etwas anders, hier sind die Browserbasierten-Dinge gemeint) kein Long DatenTyp "versteht", da aktuell nur maximal 53bit verwendet werden können, Long braucht aber bis zu 56bit, damit man hier einen Reader/Writer mit Byteshifting erstellen kann; Denn um die Long-Value zu schreiben, müsste man wie folgt shiften: 56 > 48 > 40 > 32 > 24 > 16 > 8 > 0

Leider geil. Der HTMLChat taugt zum analysieren überhaupt nichts, da es viel zu hart obfuscated ist, da hat man das ganze schneller über die Informationen über das Java-Applet zusammengebastelt.

Es gibt online eine LONG Klasse die das kann