Daten werden nicht komplett gesendet (TCP-Socket flushen?)

[Ralf Kaiser]

Hallo,

Ich versende Daten per TCP-IP von einem Clientprogramm zu einem Server. Beide Programme sind selbst geschrieben.

Intern werden die Socketverbindungen in eigenen Klassen gekapselt. Ich erzeuge die Sendeklasse, versende eine relativ geringe Menge von Daten (um die 100 Byte) und gebe die Sendeklasse wieder frei. Es kommt beim Empfänger nichts an.

ABER: Wenn ich vor der Freigabe der Sendeklasse eine kurze Pause einlege Sleep(100) dann kommen die Daten beim Empfänger an!

Im Netz habe ich verschiedene Hinweise gefunden, dass bei geringen Datenmengen erst einmal gewartet wird "ob noch mehr kommt" und dann erst wirklich gesendet wird. Scheinbar werden bei der Freigabe der Sendeklasse, welche innerhalb dieses Timeouts stattfindet, die Daten auch einfach entsorgt. Warte ich ein wenig, läuft das Timeout ab und die Daten werden gesendet bevor die Klasse freigegeben wird. (Stichwort ist hier "Nagle Algorithmus")

Weiß jemand, wie man vor dem freigeben der Sendeklasse den internen Socket dazu bewegen kann, die Daten wirklich zu senden, also quasi zu "flushen"? Bei der Freigabe wird der Socket ganz normal geschlossen und ich bin davon ausgegangen, dass dabei noch ausstehende Daten verschickt werden. Dem scheint aber nicht so zu sein.

Danke schon mal,
Ralf

[shmia]

Das Problem ist, dass du wahrscheinlich kein Protokoll auf Anwendungsebene verwendest.
Mit dem Protokoll musst du dem Epmfänger sigalisieren, wo das Datenpaket anfängt und wo es endet.
Ein einfaches Protokoll sieht so aus:

Code:

Nutzdaten CR+LF

Der Empfänger liest einfach so lange, bis er das CR+LF im Datenstrom erkannt hat und weiss dann wo die Nutzdaten enden.
Deine Idee mit Sleep() bitte ganz weit auf den Müll werfen.

[Ralf Kaiser]

Zitat von shmia:

Das Problem ist, dass du wahrscheinlich kein Protokoll auf Anwendungsebene verwendest.
Mit dem Protokoll musst du dem Epmfänger sigalisieren, wo das Datenpaket anfängt und wo es endet.
Ein einfaches Protokoll sieht so aus:

Code:

Nutzdaten CR+LF

Der Empfänger liest einfach so lange, bis er das CR+LF im Datenstrom erkannt hat und weiß dann wo die Nutzdaten enden

Na ja, ein "Protokoll" gibt es schon. Die Daten müssen nämlich eine gewisse Länge haben (die wird festgelegt, ich glaube das könnte man "Protokoll" nennen...). Das Sendeprogramm schickt auch genau diese Anzahl, das Leseprogramm holt genau diese Anzahl nur kommt eben nichts an wenn die Sendeklasse direkt freigegeben wird (und das wird wohl öfter der Fall sein).

Mit dem CRLF habe ich ausprobiert - ohne Erfolg (war wäre denn wenn CRLF in den Daten vorkommt?? - Darum wird ja die Länge festgelegt!)

Zitat von shmia:

Deine Idee mit Sleep() bitte ganz weit auf den Müll werfen.

Das war auch nur zu Testzwecken. Mir war aufgefallen, dass die Daten immer ankamen wenn irgendetwas eine Verzögerung verursachte (z.B. ein Breakpoint in der IDE)

[shmia]

Zitat von Alfi001:

Na ja, ein "Protokoll" gibt es schon. Die Daten müssen nämlich eine gewisse Länge haben (die wird festgelegt, ich glaube das könnte man "Protokoll" nennen...). Das Sendeprogramm schickt auch genau diese Anzahl, das Leseprogramm holt genau diese Anzahl

Ja eine feste Satzlänge ist ok.

Wenn ein Socket geschlossen wird, dann wird closesocket() aufgerufen.
Es hängt dann von den "Linger" -Optionen ab, ob Daten im Sendepuffer noch übertragen werden.
Besser ist es aber wenn man zuvor explizit shutdown() aufgeruft.
Ich habe mal in die Unit "ScktComp" reingeschaut:
dort wird WSACancelASyncRequest() gefolgt von closesocket() aufgerufen und das sieht also so aus als ob Daten die noch im Sendepuffer liegen tatsächlich verworfen werden.

Man könnte nun im Event OnDisconnect reagiert und dort vielleicht shutdown() aufrufen...

[Ralf Kaiser]

Daran kann es eigentlich nicht liegen...

Unsere Sendeklasse ist von TCustomIPClient (und damit von TBaseSocket) abgeleitet. Und in dieser Vererbungskette wird beim Close folgendes ausgeführt:

Delphi-Quellcode:

procedure TCustomIpClient.Close;
begin
  if FConnected then
  begin
{$IFDEF MSWINDOWS}
    ErrorCheck(shutdown(FSocket, SD_BOTH));
{$ENDIF}
{$IFDEF LINUX}
    ErrorCheck(shutdown(FSocket, SHUT_RDWR));
{$ENDIF}
    FConnected := False;
    DoDisconnect;
  end;
  inherited Close;
end;

Und dann im "inherited", also in TBaseSocket:

Delphi-Quellcode:

procedure TBaseSocket.Close;
begin
  if FActive then
  begin
{$IFDEF MSWINDOWS}
    ErrorCheck(closesocket(FSocket));
{$ENDIF}
{$IFDEF LINUX}
    ErrorCheck(Libc.__close(FSocket));
{$ENDIF}
    FSocket := INVALID_SOCKET;
    FActive := False;
    DoDestroyHandle;
  end;

end;

Es wird also zuerst "shutdown" und danach "closesocket" aufgerufen. Das sieht für mich soweit korrekt aus...