Client/Serververbindung arbeitet kurz und friert dann ein.

[BlackJack]

Moin,
ich habe ein paar Probleme mit einer Client-Server-Verbindung (mit TServerSocket & TClientSocket). Und zwar möchte ich mir einen Netzwerkrenderer für meinen Raytracer programmieren (spielt aber erstmal keine Rolle). Das ganze soll so ablaufen:

• Der Client schickt ne Nachricht zum Server, das er gerne ne Aufgabe hätte ("givejob")
• Der Server schickt einen Auftrag zum Client, was dieser tun soll ("dojob"),
• Der Client macht, was er tun soll, d.h. er rechnet ein bisschen rum
• Wenn er damit fertig ist, schickt der dem Server die Ergebnisse zurück ("donejob")
• Der Server bestätig dem Client, dass die Ergebnisse angekommen sind ("datareceived")
• Danach kann sich der Client n neuen Auftrag holen; wenn es nichts mehr zu tun gibt, anwortet der Server mit "nomorejobs"

Für das Übermittel der Nachrichten hab ich mir auch schön ein Protokoll ausgedacht: zuerst wird eine Signatur übermittelt ("lrt"), dann ein byte, das die Länge der nachfolgenden Zeichenkette angibt, und in der Zeichenkette stehen dann halt die "Auftragsstrings" drin (givejob, dojob etc.).

Im Prinzip funktioniert das ganze auch ansatzweise, allerdings kommt beim Server nach ein paar Aufträgen nichts mehr an. Und mit zwei Clients gleichzeitig kann der Server auch nicht arbeiten, dann friert er einfach so lange ein, bis einer der Clients wieder disconnected.

Meine Frage ist jetzt erstmal (da ich mich gerade erst in das Thema TCP/IP), ob ich überhaupt die Nachrichten und Daten zwischen Server richtig austausche; die entsprechenden Routinen stehen in der Unit TCPUtils.pas, aber ich poste sie trotzdem nochmal hier.

Desweiteren wolle ich mal fragen, wie man das am Besten mit der Fehlerbehandlung macht, weil teilweise der Server abstürzt, wenn ein Client disconnected etc.
Und dann natürlich noch die Frage, warum ein paar Aufträge bearbeitet werden und danach nichts mehr beim Server ankommt...

Ich hab einfach mal das gesamte Projekt in den Anhang gepackt.
Ach ja, bis jetzt ist das alles nur ein Testprojekt; das eigentliche Rechnen macht der TRenderThread in der Methode Execute(), da wird einfach ein Fraktal berechnet.

hier nochmal der Source der "Kommunikationsroutinen":

Delphi-Quellcode:

function SendData(ASocket: TCustomWinsocket; AData: Pointer; ASize: Integer;
  ATimeOut: Integer): Boolean;
  var send, tmp: Integer;
      time: Cardinal;
      PB: PByteArray;
  begin
  Result := False;
  if not ASocket.Connected then
    Exit;

  send := 0;
  time := GetTickCount;
  PB := AData;
  while send < ASize do
    begin
    tmp := ASocket.SendBuf(PB^[send], ASize-send);
    if tmp <> -1 then
      begin
      send := send + tmp;
      time := GetTickCount;
      end
    else
      if GetTickCount - time >= ATimeOut then
        Exit;
    if send <> ASize then
      Sleep(10);
    end;
  Result := True;
  end;

function ReceiveData(ASocket: TCustomWinsocket; AData: Pointer; ASize: Integer;
  ATimeOut: Integer): Boolean;
  var rec, tmp: Integer;
      time: Cardinal;
      PB: PByteArray;
  begin
  Result := False;
  if not ASocket.Connected then
    Exit;

  rec := 0;
  time := GetTickCount;
  PB := AData;
  while rec < ASize do
    begin
    tmp := ASocket.ReceiveBuf(PB^[rec], ASize - rec);
    if tmp <> -1 then
      begin
      rec := rec + tmp;
      time := GetTickCount;
      end
    else
      if GetTickCount - time >= ATimeOut then
        Exit;
    if rec <> ASize then
      Sleep(10);
    end;
  Result := True;
  end;

function ReceiveCommand(ASocket: TCustomWinSocket): string;
  var Sig: string;
      CommandLength: Byte;
      PB: PByteArray;
  begin
  Result := '';
  if ASocket.ReceiveLength < 4 then
    Exit;

  SetLength(Sig, 3);
  ReceiveData(ASocket, @Sig[1], 3);
  ReceiveData(ASocket, @CommandLength, 1);
  if Sig <> 'lrt' then
    Exit;

  SetLength(Result, CommandLength);
  ReceiveData(ASocket, @Result[1], CommandLength); {}
  end;

procedure SendCommand(ASocket: TCustomWinSocket; ACommand: string; AData: Pointer; ASize: Integer);
  var Data: string;
      l: Integer;
  begin
  Data := 'lrt' + Chr(Length(ACommand)) + ACommand;
  SendData(ASocket, @Data[1], Length(Data));
  if AData <> nil then
    SendData(ASocket, AData, ASize);
  end;

Ich bin für jede Hilfe dankbar.

[thomasdrewermann]

Hi,

ich würde der Einfachheit halbe für die Kommandos die Ereignisse Client/Server Read und Client/Server Write benutzen. Dort löst das Event immer aus, wenn er Zeichen empfängt. Der empfangene String wird dann auch direkt übergeben. Versenden auf Server-Seite geht dann mit serversocket1.Socket[nummer des verbundenen client beginnt bei client 1 mit 0].SendText, auf Client-Seite geht es mit clientsocket1.SendText weil er ja immer nur eine Verbindung hat.

Man muss nur darauf achten die empfangenen Daten sauber zu trennen, denn kruz hinter einander gesendete Zeichenketten werden manchmal als ein Event übergeben.

Hoffe zu helfen.

Gruß
Thomas

[Muetze1]

Zitat von thomasdrewermann:

ich würde der Einfachheit halbe für die Kommandos die Ereignisse Client/Server Read und Client/Server Write benutzen.

Macht er so. Wo siehst du was anderes?

Zitat von thomasdrewermann:

Dort löst das Event immer aus, wenn er Zeichen empfängt. Der empfangene String wird dann auch direkt übergeben.

Ist mir neu - wo wird denn da ein String übergeben? Du bekommst Sender übergeben und die TCustomWinSocket Instanz welche das Ereignis auslöst, aber einen String? Das wäre doch fatal wenn sich der Socket rausnehmen würde zu behaupten, ich will einen String haben. Der Socket hat gefälligst Daten zu übertragen und sich nicht anschicken zu vermuten was ich haben will - also String, ein Byte oder ein Block binäre Daten...

Zitat von thomasdrewermann:

Versenden auf Server-Seite geht dann mit serversocket1.Socket[nummer des verbundenen client beginnt bei client 1 mit 0].SendText, auf Client-Seite geht es mit clientsocket1.SendText weil er ja immer nur eine Verbindung hat.

Warum? Er antwortet direkt im OnClientRead auf die empfangenen Packete und nutzt somit die übergebene TCustomWinSocket Instanz - und die findest du auch an den von dir genannten Orten wieder. Aber wo man sie bezieht ist Schnuppe - BlackJack's Weg ist genauso machbar und stellt kein Unterschied dar.

Zitat von thomasdrewermann:

Man muss nur darauf achten die empfangenen Daten sauber zu trennen, denn kruz hinter einander gesendete Zeichenketten werden manchmal als ein Event übergeben.

... oder mehrere Events bis ein Datenteil empfangen wurde. Aber selbst darauf achtet er in seinem Code.

[BlackJack]

Zitat von Muetze1:

Zitat von thomasdrewermann:

Man muss nur darauf achten die empfangenen Daten sauber zu trennen, denn kruz hinter einander gesendete Zeichenketten werden manchmal als ein Event übergeben.

... oder mehrere Events bis ein Datenteil empfangen wurde. Aber selbst darauf achtet er in seinem Code.

Wie ist das denn, wenn ich im OnRead-Event sagen wir 50 byte gesendet bekomme (das kann ich doch über Socket.ReceiveLength erfahren, oder?), aber nur 30 Bytes über Socket.ReceiveBuffer aus dem Socket auslese. wenn dann wieder ein OnRead-Event auftritt, stehen dann "vorne im Socket" noch die restlichen 20 Byte vom vorherigen Event?

Oder umgekehrt, wenn ich 20 bytes im OnRead bekomme, aber 50 bytes aus dem Socket auslesen will, und während des Auslesens (also während ich noch auf die restlichen 30 byte warte) wird ein weiterer OnRead-Event ausgelöst. kann es dann sein dass der Event mit einem "leeren" Socket ausgeführt wird, weil ich die zugehörigen 30 bytes ja schon ausgelesen habe? weil das kommt bei mir auch manchmal vor, dass OnRead ausgeführt wird, aber Socket.ReceiveLength = 0 ist.

und ich weiss nicht genau wie ich das Onwrite benutzen soll (OnRead benutz ich ja schon). wird dieser Event nicht immer dann ausgelöst, wenn ich was mit socket.SendText/Buffer sende?

und ob ich jetzt SendText oder SendBuffer benutze sollte doch letztendlich egal sein, oder? nur dass man beim ReceiveBuffer noch angeben kann, wie viele Bytes er auslesen soll (und das ist ja wohl wichtig, wenn ich eben nicht wissen kann, ob die Nachrichten "vermischt" ankommen).

[Muetze1]

Zitat von BlackJack:

Wie ist das denn, wenn ich im OnRead-Event sagen wir 50 byte gesendet bekomme (das kann ich doch über Socket.ReceiveLength erfahren, oder?), aber nur 30 Bytes über Socket.ReceiveBuffer aus dem Socket auslese. wenn dann wieder ein OnRead-Event auftritt, stehen dann "vorne im Socket" noch die restlichen 20 Byte vom vorherigen Event?

Ja.

Zitat von BlackJack:

Oder umgekehrt, wenn ich 20 bytes im OnRead bekomme, aber 50 bytes aus dem Socket auslesen will, und während des Auslesens (also während ich noch auf die restlichen 30 byte warte) wird ein weiterer OnRead-Event ausgelöst. kann es dann sein dass der Event mit einem "leeren" Socket ausgeführt wird, weil ich die zugehörigen 30 bytes ja schon ausgelesen habe? weil das kommt bei mir auch manchmal vor, dass OnRead ausgeführt wird, aber Socket.ReceiveLength = 0 ist.

Ja. Da dein Code wartet bis die Receivelength stimmt (polling) aber der Socket mit Ereignisssteuerung arbeitet, teilt er dir durch erneutes aufrufen des OnRead mit. Da liegt auch dein Problem begraben. Dieser Aufruf wird vom Thread des Sockets ausgelöst und wird im Haupt VCL Thread Synchronisiert. Dieser hängt im Normalfall in deinem OnRead, weshalb er nicht zu Zuge kommt. Da du aber ein Sleep() drinne hast, gibst du Rechenzeit ab - u.a. an den VCL Thread, der dann dein OnRead erneut auslöst. Deine OnRead Methode wiederrum ist aber nicht reentrant ausgelegt und es kommt zu dem Problem wie von dir beschrieben.

Zitat von BlackJack:

und ich weiss nicht genau wie ich das Onwrite benutzen soll (OnRead benutz ich ja schon). wird dieser Event nicht immer dann ausgelöst, wenn ich was mit socket.SendText/Buffer sende?

Vom Namen her schon, klar - aber im NonBlocking Mode der Sockets (d.h. sie benutzen einen Thread), wird dieses Event soweit nicht ausgelöst. Ich habe dieses Event bisher auch noch nie gebraucht.

Zitat von BlackJack:

und ob ich jetzt SendText oder SendBuffer benutze sollte doch letztendlich egal sein, oder? nur dass man beim ReceiveBuffer noch angeben kann, wie viele Bytes er auslesen soll (und das ist ja wohl wichtig, wenn ich eben nicht wissen kann, ob die Nachrichten "vermischt" ankommen).

Der Buffer des Sockets ist es wurscht welche Daten in ihm liegen. Es ist ihm auch egal wie sie hineinkommen. SendBuf und SendText sind nur zwei Methoden für unterschiedliche Datentypen und somit nicht anders von der Funktionalität. Bei ReceiveText und ReceiveBuf() ist es entsprechend.

Die Sockets haben einen kleinen und begrenzten Buffer. Daher ist es nicht ratsam wissentlich Daten in einem OnRead nicht komplett auszulesen und zu warten bis die benötigte Menge an Daten empfangen ist. Es empfiehlt sich lieber einen Buffer selber an zu legen, alle Daten vom Socket in den Buffer zu schreiben (bzw. anzuhängen) und dann von vorne den Buffer durchgehen, interpretieren und schauen ob man genug empfangen hat. Dieser Teil kann immer nach einem erfolgtem OnRead ausgeführt werden. Nach erfolgreicher Interpretation einfach den Teil vorne vom Buffer entfernen. Ich habe dazu immer einen TMemoryStream verwendet und es klappte soweit alles recht gut. Beim Server muss man dann natürlich einen MemoryStream pro Client vorhalten. Ein grundlegendes Beispiel dazu könnte man sich in dem Chat auf meiner HP anschauen.

[BlackJack]

Zitat von Muetze1:

Die Sockets haben einen kleinen und begrenzten Buffer. Daher ist es nicht ratsam wissentlich Daten in einem OnRead nicht komplett auszulesen und zu warten bis die benötigte Menge an Daten empfangen ist. Es empfiehlt sich lieber einen Buffer selber an zu legen, alle Daten vom Socket in den Buffer zu schreiben (bzw. anzuhängen) und dann von vorne den Buffer durchgehen, interpretieren und schauen ob man genug empfangen hat. Dieser Teil kann immer nach einem erfolgtem OnRead ausgeführt werden. Nach erfolgreicher Interpretation einfach den Teil vorne vom Buffer entfernen. Ich habe dazu immer einen TMemoryStream verwendet und es klappte soweit alles recht gut. Beim Server muss man dann natürlich einen MemoryStream pro Client vorhalten. Ein grundlegendes Beispiel dazu könnte man sich in dem Chat auf meiner HP anschauen.

also quasi ne Warteschlange? jo ich glaube das ist ne gute idee, so werde ich das mal versuchen.
aber dann kann ich mir ja auch die eigene Methode zum Empfangen (ReceiveData) sparen, oder? weil wenn ich im OnRead einfach mit ReceiveText auslese, dann gibt er mit doch automatisch alles zurück, was der Socket grade vorliegen hat, und das kann dann einfach an die Warteschleife anhängt werden.
und ist damit dann nicht auch automatisch das Thread-Problem, das du beschrieben hast, gelöst?

Zitat von Muetze1:

Ein grundlegendes Beispiel dazu könnte man sich in dem Chat auf meiner HP anschauen.

Ich möchte es aber vorher gerne alleine hinbekommen

edit:
ach ja was haltet ihr von folgendem "Protkoll" für den austausch von Nachrichten/daten:
"lrt" ; 1 Byte für die Länge des Kommandos ; Kommandostring ; 4 Bytes für die Länge der eventuell folgenden Daten.

[Muetze1]

Zitat von BlackJack:

also quasi ne Warteschlange? jo ich glaube das ist ne gute idee, so werde ich das mal versuchen.

Joa, genau. Die nimmt alles auf was ankommt und immer wenn was hinzukommt, kannst du ja anhand deines Protokolls nachschauen ob du alles hast oder halt noch weiter warten musst.

Zitat von BlackJack:

aber dann kann ich mir ja auch die eigene Methode zum Empfangen (ReceiveData) sparen, oder?

Ja, die hättest du so oder so extra bauen können und eigentlich auch direkt in die jeweils zugewiesene Methode. Vor allem nun hast du auf der Serverseite die Verwaltung der MemoryStreams pro Client noch zusätzlich (Tipp: Schau dir die Eigenschaft Data der TCustomWinSockets an).

Zitat von BlackJack:

weil wenn ich im OnRead einfach mit ReceiveText auslese, dann gibt er mit doch automatisch alles zurück, was der Socket grade vorliegen hat, und das kann dann einfach an die Warteschleife anhängt werden.

Grundlegend richtig, aber in den Umsetzung zweifelhaft, da du mit TJob einen Record überträgst und somit würde dein String bei einem enthaltenen Nullbyte enden. Daher: Übertragung vom Socket in den TMemoryStream am besten immer mit ReceiveBuff und WriteBuffer. Andere Möglichkeit die mir hier gerade dabei einfällt:

Delphi-Quellcode:

procedure OnReceive:
begin
  MemoryStream.Position := MemoryStream.Size;
  MemoryStream.Size := MemoryStream.Size + Socket.ReceiveLength;

  Socket.ReceiveBuf(MemoryStream.Memory^, Socket.ReceiveLength);
End;

Gerade eingefallen - so spart man sich den Zwischenpuffer und das doppelte kopieren.

Zitat von BlackJack:

und ist damit dann nicht auch automatisch das Thread-Problem, das du beschrieben hast, gelöst?

Jupp!

Zitat von BlackJack:

edit:
ach ja was haltet ihr von folgendem "Protkoll" für den austausch von Nachrichten/daten:
"lrt" ; 1 Byte für die Länge des Kommandos ; Kommandostring ; 4 Bytes für die Länge der eventuell folgenden Daten.

Wie wäre es einfach nach der Kennung (die du später zum neu-synchronisieren verwenden kannst) 4 Bytes zu senden mit der Gesamtlänge? Dann könnte nämlich Server sowie Client bei unbekannten Kommandos diese überspringen - weil er zwar nicht weiss wie er sie handeln kann, aber überspringen kann er sie, da er ihre Gesamtlänge kennt.

"lrt"; 4 Bytes Gesamtlänge; 1 Byte Kommandolänge; Kommando; <abhängig vom Kommando>4 Byte Datenlänge; Daten</abhängig vom Kommando>

[BlackJack]

Zitat von Muetze1:

(Tipp: Schau dir die Eigenschaft Data der TCustomWinSockets an).

hmm so wie ich das in der hilfe verstehe zeigt Data auf einen Block, der Infos zu der jeweiligen Socketverbindung speichert. allerdings steht in der Delphi-hilfe sonst nicht viel dazu, wo kann man da denn mehr erfahren?

Zitat von Muetze1:

Andere Möglichkeit die mir hier gerade dabei einfällt:

Delphi-Quellcode:

procedure OnReceive:
begin
  MemoryStream.Position := MemoryStream.Size;
  MemoryStream.Size := MemoryStream.Size + Socket.ReceiveLength;

  Socket.ReceiveBuf(MemoryStream.Memory^, Socket.ReceiveLength);
End;

solle das dann nicht so aussehen: Socket.ReceiveBuf(Pointer(Integer(MemoryStream.Memory) + OldSize)^, Socket.ReceiveLength); weil so wie ich das verstanden habe zeigt Memory auf den Anfang der Daten, aber ich will ja ans Ende anhängen.

Zitat von Muetze1:

Wie wäre es einfach nach der Kennung (die du später zum neu-synchronisieren verwenden kannst) 4 Bytes zu senden mit der Gesamtlänge? Dann könnte nämlich Server sowie Client bei unbekannten Kommandos diese überspringen - weil er zwar nicht weiss wie er sie handeln kann, aber überspringen kann er sie, da er ihre Gesamtlänge kennt.

dann müssten aber auch wieder die Methoden zum Auslesen aus dem MemoryStream bescheid wissen, welche Kommandos es gibt und welche falsch sind. Ich wollte es eigentlich so machen, dass ich ne Funktion hab, die das Kommando ausliest (vorher Kennung checken etc) und die eventuell folgenden Daten mit zurückgibt. und die aufrufende Methode bekommt dann halt das Kommando und muss selber entscheiden, ob sie was damit anfangen kann.

und kann man das so machen dass nach dem Auslesen aus dem MemoryStream alles rigoros relöscht wird, was nicht mit "lrt" beginnt? weil sonst pack ich mir den MemoryStream ja eventuell immer voller aber lese nie was draus aus.
(apropos: wie löscht man am schlauesten die ersten n bytes aus dem MemoryStream, ohne die gesamten restlichen Daten kopieren zu müssen?)

[Muetze1]

Zitat von BlackJack:

Zitat von Muetze1:

(Tipp: Schau dir die Eigenschaft Data der TCustomWinSockets an).

hmm so wie ich das in der hilfe verstehe zeigt Data auf einen Block, der Infos zu der jeweiligen Socketverbindung speichert. allerdings steht in der Delphi-hilfe sonst nicht viel dazu, wo kann man da denn mehr erfahren?

Ist genauso wie die Data Eigenschaft der TreeNodes oder die Tag Eigenschaft der Komponenten eine ungenutzte Eigenschaft die mitgeführt wird. Du kannst die Daten selber belegen. Somit kannst du im ClientConnect einen TMemoryStream anlegen und dessen Instanz in der Data Eigenschaft des Sockets vermerken und hast ihn somit immer sofort zur Verfügung.

Zitat von BlackJack:

solle das dann nicht so aussehen: Socket.ReceiveBuf(Pointer(Integer(MemoryStream.Memory) + OldSize)^, Socket.ReceiveLength); weil so wie ich das verstanden habe zeigt Memory auf den Anfang der Daten, aber ich will ja ans Ende anhängen.

Ja, du hast vollkommen Recht, ich ging in meinem jugendlichen Leichtsinn fälschlicherweise davon aus, dass er Memory anpasst, abhängig von Position, aber dem ist nicht so.

Zitat von BlackJack:

dann müssten aber auch wieder die Methoden zum Auslesen aus dem MemoryStream bescheid wissen, welche Kommandos es gibt und welche falsch sind. Ich wollte es eigentlich so machen, dass ich ne Funktion hab, die das Kommando ausliest (vorher Kennung checken etc) und die eventuell folgenden Daten mit zurückgibt. und die aufrufende Methode bekommt dann halt das Kommando und muss selber entscheiden, ob sie was damit anfangen kann.

Warum? Die Methode kann das Kommando und den Datenblock als Pointer auslesen und zurück geben. Wenn es kein Datenblock gibt, dann gibt es ein Nil zurück. Ob es einen Datenblock gibt, erkennt die Funktion unabhängig davon welches Kommando es ist, wenn die Gesamtlänge grösser als die Kommandolänge ist (plus 1, für das Byte der Kommandolänge). Ob das Kommando nun bekannt ist, das kannst du auch ausserhalb regeln und deine Funktion kannst du so schreiben - ohne das sie näheres Wissen.

Zitat von BlackJack:

und kann man das so machen dass nach dem Auslesen aus dem MemoryStream alles rigoros relöscht wird, was nicht mit "lrt" beginnt?

Wenn du am Anfang einen Block hast, der nicht mit "lrt" beginnt, dann wurde zuviel oder zu wenig gesendet/ausgelesen. Daher müsstest du neu synchronisieren - also so lange auslesen bis du ein "lrt" findest. Aber rigeros löschen nicht, da du schon wieder Teile des nachfolgenden Blockes in dem MemoryStream haben kannst.

Zitat von BlackJack:

(apropos: wie löscht man am schlauesten die ersten n bytes aus dem MemoryStream, ohne die gesamten restlichen Daten kopieren zu müssen?)

Kenne ich keine Methode, daher CopyFrom() und die Size Eigenschaft setzen.

[BlackJack]

Zitat von Muetze1:

Ist genauso wie die Data Eigenschaft der TreeNodes oder die Tag Eigenschaft der Komponenten eine ungenutzte Eigenschaft die mitgeführt wird. Du kannst die Daten selber belegen. Somit kannst du im ClientConnect einen TMemoryStream anlegen und dessen Instanz in der Data Eigenschaft des Sockets vermerken und hast ihn somit immer sofort zur Verfügung.

jo das ist mal ne gute idee.

Zitat von Muetze1:

Warum? Die Methode kann das Kommando und den Datenblock als Pointer auslesen und zurück geben. Wenn es kein Datenblock gibt, dann gibt es ein Nil zurück. Ob es einen Datenblock gibt, erkennt die Funktion unabhängig davon welches Kommando es ist, wenn die Gesamtlänge grösser als die Kommandolänge ist (plus 1, für das Byte der Kommandolänge). Ob das Kommando nun bekannt ist, das kannst du auch ausserhalb regeln und deine Funktion kannst du so schreiben - ohne das sie näheres Wissen.

naja dann ist das ja eigentlich das gleiche wie ich es bisher auch vorhabe. wenn es keinen Datenblock gibt, dann wird einfach 0 in die Datenblocklänge geschrieben und gut ist. da überträgt man sogar genau die gleiche anzahl an bytes

Zitat von Muetze1:

Wenn du am Anfang einen Block hast, der nicht mit "lrt" beginnt, dann wurde zuviel oder zu wenig gesendet/ausgelesen. Daher müsstest du neu synchronisieren - also so lange auslesen bis du ein "lrt" findest. Aber rigeros löschen nicht, da du schon wieder Teile des nachfolgenden Blockes in dem MemoryStream haben kannst.

das zuviel/zuwenig ausgelesen wurde, kann ja eigentlich gar nicht vorkommen; ich lese ja erst dann aus dem MemoryStream aus, wenn alle Daten angekommen sind, und lösche die dann direkt aus dem Stream raus.
und zuviel oder zuwenig gesendet werden kann ja eigentlich auch nicht, dafür wird ja die Datenlänge übermittelt.
durch das weglöschen bis zum nächsten "lrt" wolle ich eigentlich verhindern, dass nicht die gesamte Warteschlange ins stocken gerät, wenn mal z.b. irgendein anderes programm was zu meinem Server hinschickt. ich würde mal sagen, wer sich nicht ans protokoll hält, ist selber schuld, oder?

Zitat von Muetze1:

Kenne ich keine Methode, daher CopyFrom() und die Size Eigenschaft setzen.

wenn ich Dest.CopyFrom(Source) mache, wie ist das dann mit den Positionen, von denen / an die kopiert wird? die Delphi-Hilfe ist da nicht ganz eindeutig....