Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Netzwerke (https://www.delphipraxis.net/14-netzwerke/)
-   -   TClientSocket Daten gehen verloren (https://www.delphipraxis.net/193977-tclientsocket-daten-gehen-verloren.html)

iphi 30. Sep 2017 19:33

TClientSocket Daten gehen verloren
 
Hallo,

mein Server sendet eine größere Datenmenge, die der Clientsocket empfangen und auch gleich verarbeiten soll.

Die Datenübertragung geht im Prinzip auch.

Mein Problem:
Wenn ich im OnRead des ClientSocket mehr mache als nur die eingegangenen Daten abzuspeichern (z.B. dekodieren), dann gehen ganze Datenblöcke verloren.
Ich habe das Gefühl, wenn ein neues Datenpaket kommt, wenn der OnRead-Handler noch beschäftigt ist, geht dieses Paket verloren. Kann das sein? Was kann man dagegen machen?

mkinzler 30. Sep 2017 19:36

AW: TClientSocket Daten gehen verloren
 
Möglicherweise durch asynchrone Verarbeitung in Threads.

iphi 30. Sep 2017 19:59

AW: TClientSocket Daten gehen verloren
 
Gibt es keinen Mechanismus, der den Datenverlust verhindert?

Ich habs eben ausprobiert: Es gehen sogar Daten verloren, wenn ich nur abspeichere, wenn Windows gleichzeitig einen hochpriorisierten Task einschiebt, z.B. beim Öffnen eines neuen Fensters.

P.S.
Ich glaub ich habs. Der Server schickt nicht alle Daten, wenn der Client beschäftigt ist.

Lösung:
Entweder den Server auf Blocking stellen oder aktiv prüfen, ob der Server alles verschickt hat.

stahli 30. Sep 2017 20:35

AW: TClientSocket Daten gehen verloren
 
Ich wollte gerade antworten, dass Du mal mehr beschreiben musst.
Dein Nachsatz passt sicher.

Für die asynchrone Kommunikation habe ich hier mal ein paar Versuche dokumentiert:
http://www.delphipraxis.net/190482-s...ockettest.html
Das ist aber eher für viele kleinere gegenseitige Nachrichten ausgelegt.

Vielleicht wären die Indys (immer blocking) auch ein sinnvoller Ansatz für Dich.

iphi 1. Okt 2017 08:43

AW: TClientSocket Daten gehen verloren
 
Danke für den Spielwiese-Link, sehr interessant.

Ich habe noch ein paar Ungereimtheiten:

Wenn ich den ServerType auf stThreadBlocking stelle, sendet der Server wie gesagt die vollständigen Datagramme an der Client. Soweit so gut. Ich sehe aber merkwürdige Nebenwirkungen:

1. Wenn sich der client mit dem Server verbindet, wird der OnClientConnect nicht mehr ausgelöst.
2. Dito bei Disconnect mit OnClientDisconnect.
3. Wenn der Client an den Server sendet, wird der Server.OnClientRead nicht mehr ausgelöst.

Habe ich da was nicht verstanden? Muss ich in dem Fall pollen?

Und noch was anderes:

Im Falle eines nichtblockierenden Servers:
Wenn ich im OnClientRead den socket.RemotePort abfrage, ist der anders als der socket.LocalPort.
Sollten die Ports nicht identisch sein, wenn Server und Client miteinander verbunden sind???

stahli 1. Okt 2017 09:19

AW: TClientSocket Daten gehen verloren
 
Deine Fragen kann ich leider nicht beantworten. Da stehe ich nicht genug im Thema. (Ich hatte mich nur soweit beschäftigt, dass mein Framework wie gewünscht funktioniert.)

Aber mal noch ein paar Fragen:
1) Arbeitest Du wirklich mit D6?
2) Was für Daten (wie große und wie häufig) werden übertragen und wie viele Clients gibt es?
3) Hast Du Dich schon mal mit den Indys beschäftigt?

iphi 1. Okt 2017 10:14

AW: TClientSocket Daten gehen verloren
 
Zitat:

1) Arbeitest Du wirklich mit D6?
2) Was für Daten (wie große und wie häufig) werden übertragen und wie viele Clients gibt es?
3) Hast Du Dich schon mal mit den Indys beschäftigt?
1.
Inzwischen arbeite ich zumeist mit Delphi7, die Unterschiede sind aber marginal.
Ich hatte mir vor langer Zeit Delphi8 angeschafft und es praktisch umgehend wieder verworfen. Allein die Installation dauerte endlos, und produzierte Fehlermeldungen ohne Ende. Wenn ich jetzt Coss-Plattform brauche, dann nehme ich Lazarus. Ich finde aber nach wie vor die irre schnelle Compilierung bei D7 extrem angenehm, daher bin ich standardmäßig bei Delphi7.

2.
ASCII-Daten (Messdaten), 3 Server, 3 Clienten, aber nur 1 zu 1 Verbindungen, maximal 1 MegaByte pro Sekunde, aber nicht echtzeitkritisch.
Das ganze ist also sehr übersichtlich, geht mit den Sockets auch gut.

3.
Indy ja, was TCP/IP anbelangt aber nicht. Für mein einfaches Problem wollte ich schlanken Code mit Bordmitteln von Delphi6/7.

mjustin 1. Okt 2017 11:17

AW: TClientSocket Daten gehen verloren
 
Zitat:

Zitat von iphi (Beitrag 1382383)
Wenn ich im OnClientRead den socket.RemotePort abfrage, ist der anders als der socket.LocalPort.
Sollten die Ports nicht identisch sein, wenn Server und Client miteinander verbunden sind???

Das würde nur eine Verbindung je Portnummer erlauben. Nimm HTTP, das mit Port 80 arbeitet: wenn der Client immer ebenfalls Port 80 verwenden müsste, könnte ein Webbrowser immer nur zu einem einzigen Webserver eine Verbindung öffnen. Praktisch ist das nicht, da man ja auch mal mehrere Browserfenster gleichzeitig öffnen will. An welches Fenster/HTTP-Verbindung soll der Server seine Datenpakete addressieren, wenn alle die gleiche Portnummer verwenden? Darum muss jeder TCP-Client eine eindeutige eigene Portnummer pro Verbindung benutzen.

iphi 1. Okt 2017 14:37

AW: TClientSocket Daten gehen verloren
 
Äh, das verstehe ich nicht.

Ich habe im Beispiel genau einen Server und einen Client und die sollen miteinander Daten austauschen in beide Richtungen.
Das geht doch nur, wenn beide dieselbe Portnummer benutzen, oder ?!?

Solange die verbunden sind, must doch der lokale Port und der Remote Port gleich sein, oder?

Redeemer 1. Okt 2017 17:56

AW: TClientSocket Daten gehen verloren
 
Der lokale Port wird gemäß Standard vom Betriebssystem zufällig zwischen 49152 und 65535 vergeben. Zu beachten ist, dass sich nur Windows (ab XP SP2) daran hält, andere Betriebssysteme ignorieren den Standard. Ist ein NAT (Router) dazwischen ändert dieser abermals den Port.

Zurück zum Thema: Was spricht gegen Indy?


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:53 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz