Konzept: Netzwerkprotokoll

[Zacherl]

Hallo zusammen,

ich habe bereits schon einige Entwürfe für ein (auf TCP aufgesetztes) Netzwerkprotokoll angefertigt, bin aber überzeugt, dass noch einiges verbessert werden kann.
Hat jemand von euch ein paar gute Konzeptvorschläge für mich? Bin dankbar für alles!

Die Hauptfunktion des Protokolls soll es sein, multiple Daten(transfers) über ein einziges Socket ablaufen zu lassen. Beispielsweise 2 Dateiübertragungen und 3 Steuerbefehle. Hierbei soll mindestens eine einfache Priorisierung möglich sein. Sprich: Auch wenn die maximale Anzahl an gleichzeitigen Transfers erreicht ist, sollen die Steuerbefehle trotzdem noch zusätzlich gesendet werden.

Folgende Grundfunktionen möchte ich zusätzlich unterstützen:
Blockweise Übertragung
Verschlüsselung & Kompression einzelner Blöcke
Suspend, Resume und Cancel einer Übertragung
Meta Daten, die zusammen mit dem Info Header sofort geschickt werden

Für meine bisherige Implementation verwende ich folgende Header:

Delphi-Quellcode:

type
  PdxIDTPMainHeader = ^TdxIDTPMainHeader;
  TdxIDTPMainHeader = packed record
    TransferID: Word;             // ID der Übertragung
    PacketSize: Word;             // Größe des aktuellen Datenblocks
    Flags: Byte;                  // optionale Flags
  end;

  TdxIDTPInfolHeader = packed record
    MetaSize: Word;               // Größe der Metadaten
    DataSize: UInt64;             // Größe der gesamt zu übertragenden Daten
    BlockSize: TdxIDTPBlockSize;  // Info: angepeilte Einzelblockgröße
    Priority: Boolean;            // Info: priorisierte Übertragung
    Encrypted: Boolean;           // Info: verschlüsselte Übertragung
    Compressed: Boolean;          // Info: komprimierte Übertragung
  end;

Auf Senderseite läuft ein Thread, welcher vorerst inaktiv wartet, bis mindestens eine Übertragung initialisiert wird. Ist dies der Fall, geht der Thread die komplette Liste mit Transfer Objekten durch und sendet in den vorgegebenen Parametern jeweils den nächsten Datenblock. Diese Schleife wird wiederholt, bis keine ausstehende Übertragung mehr vorhanden ist.

Delphi-Quellcode:

procedure TdxIDTPSendThread.Execute;
var
  List: TList;
  ListCopy: array of TdxIDTPOTransfer;
  Transfer: TdxIDTPOTransfer;
  I, NormalCount: Integer;
begin
  while (not Terminated) do
  begin
    // Transfer Objekte aus der gesicherten Liste kopieren. Von außerhalb
    // können danach zwar Übertragungen hinzugefügt oder deren Reihenfolge
    // geändert werden, was aber keinen Einfluss auf den aktuellen Durchlauf
    // hat.
    // ACHTUNG: Niemals Transfer Objekte außerhalb dieses Threads manuell
    //          freigeben!
    List := FIOHandler.OutgoingTransfers.LockList;
    try
      // Abgeschlossene Übertragungen entfernen
      for I := List.Count -1 downto 0 do
      begin
        if (TdxIDTPOTransfer(List.Items[I]).TransferState = tsFinished) then
        begin
          TdxIDTPOTransfer(List.Items[I]).Free;
          List.Delete(I);
        end;
      end;
      // Kopie der Liste anfertigen
      // TODO: Hier suspendierte Transfers nicht kopieren!
      //       Ausnahme: PendingStatusUpdate = true oder HeaderSent = false
      SetLength(ListCopy, List.Count);
      for I := 0 to List.Count - 1 do
      begin
        ListCopy[I] := TdxIDTPOTransfer(List.Items[I]);
      end;
    finally
      FIOHandler.OutgoingTransfers.UnlockList;
    end;
    // Thread suspendieren, wenn keine Transfers aktiv sind
    if (Length(ListCopy) = 0) then
    begin
      ResetEvent(FWaitEvent);
      WaitForSingleObject(FWaitEvent, INFINITE);
    end;
    if Terminated then
    begin
      Break;
    end;
    // Transferliste abarbeiten
    NormalCount := 0;
    for I := 0 to High(ListCopy) do
    begin
      Transfer := ListCopy[I];
      // Maximale gleichzeitige Transfer Anzahl erreicht. 
      // Transfer überspringen, wenn es kein priorisierter Transfer ist,
      // der Info Header schon gesendet wurde und kein Update
      // des Transfer Status gesendet werden muss
      if ((NormalCount >= FIOHandler.OutgoingTransferCountLimit) and
        (not Transfer.Priority)) and (Transfer.HeaderSent) and
        (not Transfer.PendingStatusUpdate) then
        Continue;
      // Transfer ist inaktiv
      if (Transfer.TransferState = tsSuspended) and
        (not Transfer.PendingStatusUpdate) then
        Continue;
      // Transfer ist abgeschlossen
      if (Transfer.TransferState = tsFinished) then
        Continue;
      // Transferzahl erhöhen
      if (not Transfer.Priority) then
      begin
        Inc(NormalCount);
      end;
      // anstehende Daten senden
      Transfer.SendNextPacketData;
    end;
    Sleep(1);
  end;
end;

Hier ist auch schon die erste Sache, die mich etwas stört: Der Thread verbraucht, durch die Schleife bedingt, relativ viel CPU Zeit. Das Sleep(1) schafft schon etwas Abhilfe, verringert natürlich aber auch deutlich die Übertragungsgeschwindigkeit.

Vor jeder Art von Daten wird ein TdxIDTPMainHeader gesendet, welcher die ID der Übertragung, die Größe des Aktuellen Blocks und weitere Flags beinhaltet. Beim Start eines Transfers enthält der erste Block den TdxIDTPInfoHeader. Dort enthalten sind Informationen, wie beispielsweise die Gesamtgröße der zu übertragenden Daten. Sind Meta Informationen angegeben, so werden auch diese direkt beim Start des Transfers an den Empfänger geschickt. Damit ist die Initialisierung abgeschlossen.
Jetzt wird je nach eingestellter Priorisierung und maximaler Transfer Anzahl jeweils der nächste Datenblock gesendet, bis alle Übertragungen abgeschlossen sind.

Die Zuordnung auf Empfängerseite erfolgt über die TransferID. Hier habe ich momentan ein statisches Array mit 1024 * 64 Elementen, in dem ich dann jeweils der Transfer ID entsprechend ein Objekt anlege, welches für das Sammeln der Daten zuständig ist.
Hier ist die zweite unschöne Sache. "Theoretisch" wäre es möglich, dass hier eine Art Überlauf stattfindet, wenn mehr als 2^16 Übertragungen gleichzeitig aktiv sind (oder zumindest in der Liste). Hier könnte ich zwar das Transfer ID Feld auf ein DWord erweitern. Das hätte aber zur Folge, dass bei jedem Datenpaket 2 zusätzliche Bytes gesendet werden und ich außerdem auf der Empfängerseite auf ein dynamisches Array umsteigen müsste (was von der Performance her sehr viel langsamer durchsucht und verwaltet werden kann).

Das dritte Problem liegt in der Verschlüsselung & Kompression begründet. Sind hier beispielsweise die Schlüssel unterschiedlich, bekommt der Decompressor Daten, mit denen er nichts anfangen kann, was zu einer Exception führt. Meine Frage ist nun, wie ich diese Exception am besten signalisieren soll? Über ein Event vielleicht? Außerdem müsste der Senderseite im Optimalfall gesagt werden, dass der Transfer abzubrechen ist.

Ich hoffe ihr habt ein paar nützliche Ideen für mich. Das Protokoll werde ich selbstverständlich hier zur Verfügung stellen, sobald alles zu meiner Zufriedenheit funktioniert.

Viele Grüße
Zacherl

[BUG]

Zitat von Zacherl:

Hier ist auch schon die erste Sache, die mich etwas stört: Der Thread verbraucht, durch die Schleife bedingt, relativ viel CPU Zeit. Das Sleep(1) schafft schon etwas Abhilfe, verringert natürlich aber auch deutlich die Übertragungsgeschwindigkeit.

Vielleicht sollte man das über die Thread-Priorität regeln.

Die anderen Dinge würde ich wie folgt angehen:

Brauchst du wirklich mehr als 2^16 Verbindungen? Schon eine 2^16 Lookup-Table ist imho ziemlich groß.

Dann würde ich vorschlagen, dass der Empfänger das erste Paket bestätigen muss ... damit gibt er bekannt, das er genug Ressourcen (und Fähigkeiten*) für diese Verbindung hat und das der Schlüssel richtig ist. Im ersten Paket gibt es bei verschlüsselten Verbindungen eine verschlüsselte Zufallszahl (Challenge), die der Empfänger entschlüsselt** wieder zurücksenden muss. Wichtig wäre dabei: Priorisierte Nachrichten sollten immer eine vorbereitete Verbindung haben.

Wenn du die Zuordnungstabelle auf Empfängerseite besser verwalten willst, dann lass den Sender eine eigene Nummer zurücksenden, die der Sender ab jetzt benutzen soll. Der Empfänger meldet sich weiter mit der ursprünglichen ID an den Sender.

Wenn der Sender oder Empfänger eine Verbindung (Chancel) abbrechen wollen, schicken sie ein Paket, das auch den Grund nennt (User/Fehler/...). Das kann er auch senden, wenn er die Verbindung nicht haben will.


*Das gibt dir die Möglichkeit, eine light-Version des Protokoll zu benutzen, z.B. ohne Kompression.
** Achtung: Gute Verschlüsselung verwenden.

[Zacherl]

Hallo BUG, danke für deine Antwort.

Zitat von BUG:

Vielleicht sollte man das über die Thread-Priorität regeln.

Gute Idee

Zitat von BUG:

Brauchst du wirklich mehr als 2^16 Verbindungen? Schon eine 2^16 Lookup-Table ist imho ziemlich groß.

Ich bezweifele es, würde aber trotzdem lieber auf Nummer sicher gehen.

Zitat von BUG:

Dann würde ich vorschlagen, dass der Empfänger das erste Paket bestätigen muss ... damit gibt er bekannt, das er genug Ressourcen (und Fähigkeiten*) für diese Verbindung hat und das der Schlüssel richtig ist. Im ersten Paket gibt es bei verschlüsselten Verbindungen eine verschlüsselte Zufallszahl (Challenge), die der Empfänger entschlüsselt** wieder zurücksenden muss. Wichtig wäre dabei: Priorisierte Nachrichten sollten immer eine vorbereitete Verbindung haben.

Im Prinzip auch eine Gute Idee. Vorbereitete Verbindungen sind immer schwierig, da ich mir nie sicher sein kann wie viele priorisierte Nachrichten unter Umständen gleichzeitig geschickt werden. Das Challenge und Capabilities Ping Pong Prinzip werde ich wohl als extra Funktion einbauen, um die Verschlüsselung und Kompression abzusichern. Allerdings werde ich es hier so handhaben, dass entweder der Client oder Server (je nachdem wer das erste Paket sendet) hier manuell tätig werden muss. In einem Event signalisiere ich dann auf beiden Seiten, dass die Verbindung abgesichert ist. Danach erst können "normale" Pakete gesendet werden.

Zitat von BUG:

Wenn du die Zuordnungstabelle auf Empfängerseite besser verwalten willst, dann lass den Sender eine eigene Nummer zurücksenden, die der Sender ab jetzt benutzen soll. Der Empfänger meldet sich weiter mit der ursprünglichen ID an den Sender.

Kannst du eventuell eine Vermutung bezüglich der Performance antizipieren? Das Protokoll soll unter anderem in einem Reverse SOCKS5 Proxy zum Einsatz kommen. Bei meinem ersten Versuch habe ich pro Verbindung ein neues Socket erstellt, dann die Challenge ausgetauscht und dann mit der Datenübertragung begonnen. Das war enorm langsam. Bin mir aber nicht sicher, ob es an den immer neuen Sockets (ohne Thread Pool etc) lag oder am Key Exchange.

Zitat von BUG:

Wenn der Sender oder Empfänger eine Verbindung (Chancel) abbrechen wollen, schicken sie ein Paket, das auch den Grund nennt (User/Fehler/...). Das kann er auch senden, wenn er die Verbindung nicht haben will.

Klingt nett. Bisher habe ich ein Flag für Suspend, Resume und Cancel vorgesehen. Dort könnte ich im Datenteil des Pakets mit Leichtigkeit noch eine Fehler ID übertragen.

[BUG]

Zitat von Zacherl:

Kannst du eventuell eine Vermutung bezüglich der Performance antizipieren? Das Protokoll soll unter anderem in einem Reverse SOCKS5 Proxy zum Einsatz kommen. Bei meinem ersten Versuch habe ich pro Verbindung ein neues Socket erstellt, dann die Challenge ausgetauscht und dann mit der Datenübertragung begonnen. Das war enorm langsam. Bin mir aber nicht sicher, ob es an den immer neuen Sockets (ohne Thread Pool etc) lag oder am Key Exchange.

Discleamer: Ich habe keine praktischen Erfahrungen im Protokolldesign, sondern zehre von einer mageren Netzwerkvorlesung

Wenn du kleine Datenmengen (HTTP) pro Verbindung gesendet hast, dann würde ich vermuten, das der Aufwand für eine neue Verbindung (Handshake, usw.) mit rein spielen könnte. Aber auch ein Key-Exchange nötigt dir ja mindestens eine Round-Trip-Time als Wartezeit auf.

Mal so aus Interesse: Wo genau kommt denn das Protokoll ins Spiel?

[Zacherl]

Zitat von BUG:

Wenn du kleine Datenmengen (HTTP) pro Verbindung gesendet hast, dann würde ich vermuten, das der Aufwand für eine neue Verbindung (Handshake, usw.) mit rein spielen könnte. Aber auch ein Key-Exchange nötigt dir ja mindestens eine Round-Trip-Time als Wartezeit auf.

Exakt. Meine Vermutung war auch eher, dass das Aufbauen der TCP Verbindung die meiste Zeit in anspruch nimmt. Habe damals leider versäumt es ohne den Key Exchange zu testen. Der Sourcecode ist unvorteilhafterweise auch mittlerweile im Nirvana verschollen.

Hat vielleicht noch jemand anders hiermit Erfahrungen gemacht?

Zitat von BUG:

Mal so aus Interesse: Wo genau kommt denn das Protokoll ins Spiel?

Primär wollte ich das Protokoll in einem reverse Proxy für Browser verwenden. Priorisierung kommt dann ins Spiel, wenn man darüber beispielsweise richtig Dateien runterläd. Dann sollen die normalen Website Downloads normal weiterlaufen, während aber nach 3 parallelen Datei Downloads erstmal Schluss ist.
Mein zweiter Ansatz lief damals schon über eine frühe Version meines Protokolls, was ich hier zu optimieren versuche. Hierbei wurden die Websiten in jedem Fall deutlich schneller aufgerufen, als bei der Multi Socket Variante. Dort war aber auch kein Key Exchange enthalten, deshalb habe ich hier wieder keinen direkten Vergleich.

[shmia]

Also ich habe mir dazu auch schon mal Gedanken gemacht und bin auf folgendes Protokoll gekommen:

Delphi-Quellcode:

TMessageHeader = packed record
  BlockSize: Word; // Größe des aktuellen Datenblocks (inkl. Header)
  StreamNo : Byte; // 0=Command Stream, 1..255=Data Streams
  Payload : Array[0..0] of Byte;  // Nutzdaten
end;

Damit können bis zu 256 unabhängige Streams über die gleiche TCP-Verbindung gemultiplexed werden.
Nach Aufbau der TCP/IP-Verbindung ist nur der Command-Stream (0) offen.
Der Client sendet dann z.B. einen Befehl an den Server:

Code:

SENDFILE test.dat

Der Server antwortet

Code:

ACK Stream 2

Die Daten werden dann blockweise mit StreamNo=2 übertragen.
Zum Schluss wird eine Message ohne Payload geschickt um den Stream wieder zu schliesen.

Der Charme dieses Protokolls ist seine Einfachheit. (das Protokoll im Command-Stream gehört aber nicht dazu. Das SENDFILE oben war nur ein Anwendungsbeispiel)
Man kann es unabhängig vom Einsatzzweck benützen.