Konzept: Netzwerkprotokoll

[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

[Zacherl]

Schonmal vielen Dank für eure Antworten!

Zitat von Sir Rufo:

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

Diese Informationen sollten eigentlich alle im Thread sein. Der IOHandler stellt nach außen hin zwar auch eine Liste mit den ein- und ausgehenden Transfers zur Verfügung (FITransferList und FOTransferList), aber die sind eigentlich nur zum Ändern der Reihenfolge durch den Benutzer gedacht (bei ausgehenden Übertragungen). Im Grunde genommen ist der IOHandler nur ein Wrapper für den IOThread, weil ich nicht wollte, dass man von außen auf die threadspezifischen Methoden wie z.b. Suspend oder Terminate zugreifen kann. Du hast allerdings Recht, dass meine Logik da inkonsistent ist. Ich müsste die besagten Listen entweder auch in die Thread Klasse verschieben oder wirklich alles aus dem Thread in die IOHandler Klasse.

Zitat von Sir Rufo:

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

Der Thread wird vom IOHandler erzeugt und freigegeben. Die Terminate Methode des Threads habe ich so überschrieben, dass dort zusätzlich das FWaitEvent gesetzt wird. Also die Terminierung des Threads sollte soweit funktionieren (hat sie auch in meinen Tests ). Die Instanz des IOHandlers übergebe ich dem Thread momentan noch, damit er auf die FOTransferList im IOHandler zugreifen kann.

Wer sich die aktuelle Implementierung mal als Ganzes anschauen möchte:
http://www.delphipraxis.net/170565-n...-new-post.html

[Sir Rufo]

Zitat von Zacherl:

Also die Terminierung des Threads sollte soweit funktionieren (hat sie auch in meinen Tests ).

Ich habe auch nicht gesagt, dass das nicht funktioniert, es gibt aber ein ganz schmales Zeitfenster, wo das nicht funktioniert.
Das doofe daran ist, wenn man es gar nicht gebrauchen kann, dann schlägt das zu (Murphy)

Hier mal mein Vorschlag für den Händler:

Delphi-Quellcode:

TIOHandler = class
private
  FSendQueue, FWaitQueue : TQueue<TdxIDTPOTransfer>;
  ...
protected
  ...
  procedure SendDataPacket;
  ...
end;

TIOHandler.SendDataPacket;
var
  Transfer : TdxIDTPOTransfer;
begin
  { CRITICAL-SECTION START }

  // Aus der Queue entnehmen
  Transfer := FSendQueue.Dequeue;

  { CRITICAL-SECTION ENDE }

  // Senden
  Transfer.SendNextPacketData;

  // Diesen Teil würde ich auch in eine eigene Methode packen, da diese auch aufgerufen werden sollte, 
  // wenn eine neue Transfer-Instanz hinzukommt

  { CRITICAL-SECTION START }

  // Mal schauen, was mit der Instanz weiter passieren soll
  if 
    ( Transfer.TransferState = tsActive {?} ) 
  and 
    ( Transfer.Priority or ( FSendQueue.Count < OutgoingTransferCountLimit ) )
  then
    FSendQueue.Enqueue( Transfer )
  else
    if 
      ( Transfer.TransferState <> tsFinished ) 
    then
      FWaitQueue.Enqueue( Transfer )
    else
      Transfer.Free;

  while ( FSendQueue.Count < OutgoingTransferCountLimit ) and ( FWaitQueue.Count > 0 ) do
    FSendQueue.Enqueue( FWaitQueue.Dequeue );

  if ( FSendQueue.Count = 0 ) then // hier noch die Abfrage rein, ob der Thread nicht eigentlich beendet werden soll
    ResetEvent( SendThread.WaitEvent )
  else
    SetEvent( SendThread.WaitEvent );

  { CRITICAL-SECTION ENDE }

end;