Konzept: Netzwerkprotokoll

[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.

[Zacherl]

Habe noch bis früh heute morgen am Protokoll gearbeitet und einige Ideen von hier wieder verworfen, geändert oder neue Sachen hinzugefügt. Das Senden und Empfangen ansich funktioniert nun schon überraschend gut. Fehlen nur noch einige Events, das automatische Sammeln der Daten, ein paar Fehlerkorrekturen und ausführliche Tests.

Meine Hauptpakete sind folgende:

Delphi-Quellcode:

type
  TdxIDTPPacketType = (
    ptTransferInfo             =  1,
    ptTransferData             =  2,
    ptTransferStateChanged     =  3,
    ptTransferStateCommand     =  4
  );
  
  TdxIDTPMainHeader = packed record
    TransferID: Word;
    PacketSize: Word;
    PacketType: TdxIDTPPacketType;
  end;

  // Diesem Paket folgen direkt die Meta Daten, fals vorhanden
  PdxIDTP1Packet = ^TdxIDTP1Packet;
  TdxIDTP1Packet = packed record
    Magic: DWord;                
    MetaSize: Word;
    DataSize: UInt64;
    BlockSize: TdxIDTPBlockSize;
    Priority: Boolean;
    Encrypted: Boolean;
    Compressed: Boolean;
  end;

  PdxIDTP2Packet = ^TdxIDTP2Packet;
  TdxIDTP2Packet = packed record
    Magic: DWord;                
    TransferState: TdxIDTPTransferState;
    Reason: TdxIDTPTransferStateChangeReason;
  end;

Der Main Header enthält wie vorher die ID der Übertragung, die aktuelle Blockgröße und den Typ der folgenden Daten.
ptTransferInfo ist praktisch das Initialisierungspaket für einen neuen Transfer. Es enthält das TdxIDTP1Packet gefolgt von eventuellen Meta Daten. Der Empfänger reagiert auf das Paket, indem es ein neues Transfer Objekt anlegt und in der LookupTable einträgt
ptTransferData enthält jeweils einen Datenblock eines Transfers. Der Empfänger prüft, ob der Transfer in der LookupTable vorhanden ist und akkumuliert die Daten. Wenn die TransferID nicht existiert, wird das Paket schlicht und einfach verworfen.
ptTransferStateChanged wird vom Sender geschickt, wenn der User eine Übertragung pausiert, fortsetzt oder abbricht. Der Empfänger ändert auf seiner Seite dann ebenfalls den Status des Transfers. Wenn die TransferID nicht existiert, wird auch hier das Paket einfach verworfen.
ptTransferStateCommand wird vom Empfänger an den Sender geschickt, wenn der User eine Übertragung pausiert, fortsetzt oder abbricht. Der Sender antwortet darauf mit einem ptTransferStateChanged Packet.

Das Magic Feld in den Control Paketen beinhaltet einen festen Wert, welcher nach der Entschlüsselung geprüft wird. Ist der Wert falsch, kann davon ausgegangen werden, dass unterschiedliche Verschlüsselungroutinen oder Schlüssel zum Einsatz kommen. Die Pakete werden dann auf Seite des Empfängers verworfen (hier könnte man sich eventuell noch etwas überlegen, um den Sender zu informieren).

Die Ping Pong Variante beim Start eines Transfers habe ich komplett verworfen. Ausgehend davon, dass die LookupTabelle auf Sender und Empfängerseite eigentlich immer synchronisiert sein sollte, kann der Sender bereits feststellen, ob bereits 2^16 Transfers laufen. Die Funktion zum Ermitteln der nächsten freien TransferID ist folgender:

Delphi-Quellcode:

function TdxIDTPIOHandler.SearchNextTransferID(var TransferID: Word): Boolean;
var
  I: Word;
begin
  Result := false;
  if (FLastTransferID = MAXWORD) then FLastTransferID := 0;
  for I := FLastTransferID to High(FOLookupTable) do
  begin
    if not Assigned(FOLookupTable[I]) then
    begin
      TransferID := I;
      Result := true;
      FLastTransferID := TransferID;
      Exit;
    end;
  end;
  for I := Low(FOLookupTable) to FLastTransferID do
  begin
    if not Assigned(FOLookupTable[I]) then
    begin
      TransferID := I;
      Result := true;
      FLastTransferID := TransferID;
      Break;
    end;
  end;
end;

Schlägt die Funktion fehl, wird eine Exception geschmissen.

Was sagt ihr zur bisherigen Umsetzung? Auf den ersten Blick scheint mir das Protokoll recht stabil zu funktionieren. Seht ihr noch irgendwelche Sachen, die extrem umgeschickt gelöst sind?

[Furtbichler]

Wenn Du mit 2^16 Übertragungen rechnest, solltest Du deine Lookuptabelle nicht als unsortiertes Array konzipieren. Verwende lieber doppelt-verkettete Liste für die freigegebenen Sende-IDs.

Delphi-Quellcode:

Function GetNewID : Integer;
Begin
  If FreeList.IsEmpty Then begin
    If HighestID = MAXWORD Then Raise Exception....;
    HighestID := HighestID + 1;
    Result := HighestID;
  End 
  else Begin
    Result := FreeList.First;
    FreeList.RemoveFirstElement;
  End;
End;

Procedure DiscardUsedID (aIDWhichIsNoLongerInUse : Integer);
Begin
  FreeList.InsertAtFront(aIDWhichIsNoLongerInUse);
End;

So ist der Aufwand immer O(1), anstatt O(n) bei deiner Variante.

[Zacherl]

Auf die Idee eine verkettete Liste zu verwenden, bin ich gar nicht gekommen. Werde ich direkt umsetzen, danke dir

[Furtbichler]

Ach ja, und wenn Du ein Speicherfetischist bist, kannst Du 'HighestID' auch wieder dekrementieren, solange der Wert 'HighestID' in der FreeList enthalten ist. Das allerdings geht auf Kosten der Performance, aber nur im Extremfall, wenn man nämlich sehr viele IDs anfordert und sie in umgekehrter Reihenfolge wieder freigibt.

[BUG]

Wenn das Protokoll erstmal feststeht, kann man sicher noch beliebig optimieren.
Denkbar fände ich zum Beispiel eine mehrstufige Abbildung der IDs. Damit sparst du auch im angesprochenen Extremfall noch Speicher
Interessant könnte auch das Minimieren von Kopieroperationen (ganz abgesehen von Speicherallokation/-freigabe) innerhalb der Implementation sein (=> Allgemein, habe mir die Implementation noch nicht angeguckt).

[Sir Rufo]

Zu deinem Thread.Execute:

IMHO machst du da zuviel Gedöns in dem Thread, was da nicht hingehört.

Der IOHandler hat alle Informationen, wie was wo gesendet werden soll, allerdings nicht direkt wann, das kommt ja im Thread.

Also würde ich den Thread auf seine wesentlichen Sachen reduzieren und dann sieht das wie folgt aus

Delphi-Quellcode:

procedure TdxIDTPSendThread.Execute;
begin
  while not Terminated do
    begin
      WaitForSingleObject( FWaitEvent, INFINITE );
      if not Terminated then
        FIOHandler.SendDataPacket;
    end;
end;

Allerdings würde ich den IOHandler nicht an den Thread hängen, sondern den Thread an den IOHandler. Dann gibt es auch kein Gerangel wer den Thread beenden kann (wird ja auch über das FWaitEvent gesteuert).
Es könnte passieren, dass trotz Terminate der Thread nicht aufhört, weil direkt nach dem Terminate der Thread selber das FWaitEvent zurücksetzt