![]() |
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? |
AW: TClientSocket Daten gehen verloren
Möglicherweise durch asynchrone Verarbeitung in Threads.
|
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. |
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: ![]() 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. |
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??? |
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? |
AW: TClientSocket Daten gehen verloren
Zitat:
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. |
AW: TClientSocket Daten gehen verloren
Zitat:
|
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? |
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:02 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz