1. #1

    Registriert seit
    28.10.2011
    Beiträge
    625
    Thanked 279 Times in 168 Posts

    Standard [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:
    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:
    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:
    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 -
    Geändert von Bubble Gum (21.04.2018 um 01:07 Uhr) Grund: Fix - Table

  2. The Following User Says Thank You to Bubble Gum For This Useful Post:

    DotNet (21.04.2018)

  3. #2

    Registriert seit
    13.02.2011
    Beiträge
    54
    Thanked 79 Times in 49 Posts

    Standard AW: [GenericProtocol] Aufbau

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

  4. The Following User Says Thank You to silently For This Useful Post:

    Bubble Gum (21.04.2018)

  5. #3

    Registriert seit
    13.02.2011
    Beiträge
    54
    Thanked 79 Times in 49 Posts

    Standard AW: [GenericProtocol] Aufbau

    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.

  6. #4

    Registriert seit
    28.10.2011
    Beiträge
    625
    Thanked 279 Times in 168 Posts

    Standard AW: [GenericProtocol] Aufbau

    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:

    <Version>;<Offset>;[<Token>;<Token>;<Token>;];<?>;;<?>;;;[<Assignment>;;<Assignment>;;][....]
    Daraus resultiert folgendes (gekürzt):
    -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:
    <ID>;;
    Multiple-Assignments:
    <ID>;<ID>;<ID>;<ID>;;
    Geändert von Bubble Gum (24.04.2018 um 02:12 Uhr)

  7. #5

    Registriert seit
    13.02.2011
    Beiträge
    54
    Thanked 79 Times in 49 Posts

    Standard AW: [GenericProtocol] Aufbau

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

  8. #6

    Registriert seit
    28.10.2011
    Beiträge
    625
    Thanked 279 Times in 168 Posts

    Standard AW: [GenericProtocol] Aufbau

    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.

  9. #7

    Registriert seit
    13.02.2011
    Beiträge
    54
    Thanked 79 Times in 49 Posts

    Standard AW: [GenericProtocol] Aufbau

    Es gibt online eine LONG Klasse die das kann

Ähnliche Themen

  1. Jobs mit Höhe(Aufbau,Wartung u.s.w)
    Von SphinxDOPE im Forum Bildung
    Antworten: 2
    Letzter Beitrag: 18.06.2016, 23:13
  2. Gute Strategie/Aufbau Spiele?
    Von jo1234 im Forum Strategiespiele
    Antworten: 36
    Letzter Beitrag: 14.08.2014, 14:46
  3. Perfekter Aufbau, Verbrennungs und Trainings-Plan
    Von Luii im Forum Sport & Gesundheit
    Antworten: 3
    Letzter Beitrag: 06.02.2014, 07:18
  4. Win7 Aufbau Spiel
    Von IceNet im Forum Windows
    Antworten: 3
    Letzter Beitrag: 04.08.2012, 13:46
  5. Aufbau/Strategie-Spiele
    Von IceNet im Forum Gaming Allgemein
    Antworten: 9
    Letzter Beitrag: 04.04.2012, 02:56
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.