Hallo,
ich habe mir eine Client-Server Lösung mit den Indy - UDP Komponenten gebaut.

Der Client und Server haben die gleiche Portadresse. Die IP Adresse ist für jeden Rechner fest eingestellt.
Der Server antwortet auf eine Datenübertragung mit ACK (Im Fehlerfall NoACK)
Fällt die Verbindung aus, weil z.B. der Server gestoppt wurde, dann sendet der Client zyklisch
eine Anfrage an den Server, bis dieser mit ACK antwortet.

Ich habe jetzt den eigenartigen Effekt das manchmal nach einer Verbindungsunterbrechung der Server die Daten empfängt und korrekt mit ACK beantwortet.
Die Information kommt aber nicht beim Client an.
Der Effekt tritt nur zeitweise auf. Ein Wechsel der Portadresse bringt nichts.
Hat wer eine Idee, woran das liegen kann ?

Der Client ist als Thread angelegt.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TUPDClient.Execute;
var
    LCS: TCriticalSection;
begin
   NameThreadForDebugging('UDPTransfer');
   FClient.Active := true;
   //FClient.ReceiveTimeout := FTimeout;
   LCS := TCriticalSection.Create;

   while not (Terminated) do
   begin
     LRead := '';
     ReceiveString := '';
     if FClient.Active then
     begin
       LCS.Enter;
       try
         LRead := FClient.ReceiveString;
         ReceiveString := LRead;
       except
         ServerConnect := false;
       end;
       LCS.Leave;
     end;
     if (aState = udp_WaitServerRequest) and (TimerStart > 0) and (GetTickCount - TimerStart > Timeout) then
     begin
       aState := Err_UDPServerRequest;
       TimerStart := 0;
       runServerConnect := false;
       flagWaitServerRequest := false;
       Synchronize(ExecuteUDP);
       end;
     If Lread='' then sleep(1)
     else
     begin
       TimerStart := 0;
       Synchronize(ExecuteUDP);
     end;
  end;
  LCS.Enter;
  if FClient.Active then
    FClient.Active := false;

  FClient.Free;
  LCS.Leave;
  LCS.Free;
end;

Hat wer eine Idee?

Gruß
Peter

UDP hat doch gerade gegenüber TCP die Eigenschaft, dass nicht sichergestellt ist, ob die Daten auch ankommen:

Zitat von http://de.wikipedia.org/wiki/User_Datagram_Protocol:

UDP stellt einen verbindungslosen, nicht-zuverlässigen Übertragungsdienst bereit. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen beinhalten.

Zitat von blackfin:

UDP hat doch gerade gegenüber TCP die Eigenschaft, dass nicht sichergestellt ist, ob die Daten auch ankommen:

Meine Frage war nicht was UDP ist, das wei0 ich selber genau und äh ich kann schon lesen und Wikepedia ist mir nicht völlig unbekannt.
Meine Frage ist, ob wer eine Idee hat, woran es liegen kann, dass alle gesendeten Pakete beim Client nicht mehr ankommen?

Peter

goto #2

Guten Abend,

sind die Rechner im einem LAN miteinander verbunden - oder liegt das "Internet dazwischen"?

Hast Du die Möglichkeit den Traffic mitzuschneiden (mit Wireshark ..)?

Liegt eventuell ein Fehler im Client vor?

Grüße
Klaus

ReceiveString() ist soviel ich weiss blocking bzw. hat standardmäßig ein unendliches Timeout.
Nur eine vermutung (habe mit Indy-UDP noch nie gearbeitet): Kann es sein, dass bei einem Verbindungsabbruch während ReceiveString() ein Fehler auftritt ("connection reset" oder dergleichen) und noch Daten im Receive-Buffer hängen, so dass der Client nie weitergeht?

P.S.: Ich wollte mit meinem Beitrag nicht "klugscheissen" oder dir an den Karren pissen. Wenn dir das so vorkam, sorry, aber es hätte ja sein können, dass du nicht gewusst hast, dass bei UDP nicht unbedingt immer alle Daten ankommen...

Die Rechner hängen normal im Lan. (Betriebsnetz) und stehen beide auf meinem Schreibtisch, da ich die Lösung erst erprobe. (Ist die Protokollierung einer Maschinensteuerung.)
Die Frage stelle ich deshalb weil ich zu den Indys, je tiefer ich eindringe, immer weniger Vertrauen habe.
Ich verwende einen eigenen Timeout. Kommt innerhalb einer bestimmten Zeit keine Antort, dann setze ich die Steuerung komplett zurück und der Client sendet zyklisch einen Request an den Server. Ist der Server nicht bereit, dann wird die Ablaufsteuerung rückgesetzt und nach 3 Sek. ein neuer Request gesendet.
Der Server empfängt diesen auch und antwortet mit ACK (Ich schreibe ein Logfile.). Diese Antwort ( über die Bindings oder auch an den Serverport adressiert) kommt aber nicht an.
Ich will probieren den Verkehr mit zu protokollieren, da fehlt mir im Moment aber noch ein Tip für ein geeignetes Werkzeug.

Und an blackfin, sorry wenn meine Antwort ungehalten klang, war nicht so gemeint.
Mir passiertes bei einer Frage in diesem Forum in letzter Zeit halt öfter mal, dass man eine Antwort erhält, die völlig an der Fragestellung vorbeigeht. Irgendwann ist die eigentliche Frage total zerredet.
Ich selbst bin Diplominformatiker und seit über 40 Jahren im Fach. Mein erstes "größeres" Programm war 2.500 Lochkarten lang.
Wenn ich ein Thema angehe, dann beschäftige ich mich erst mit den Grundlagen. Um das Rad nicht nochmal zu erfinden, suche ich im Netz zwar nach vorhandenen Code.
Den verwende ich aber erst, wenn ich die Funktionalität verstanden habe.


Peter

Schon ok

Zitat:

Ich will probieren den Verkehr mit zu protokollieren, da fehlt mir im Moment aber noch ein Tip für ein geeignetes Werkzeug.

Klaus01 hat ja bereits Wireshark erwähnt. Ich denke, damit solltest du alles sehen können, was über das Netzwerk läuft.

Achja, evtl. hilft dir bei dem Problem auch noch dieser Beitrag aus den EDN-Foren.

Wenn Server und Client den gleichen UDP-Port benützen, wie verhinderst du dann, dass jeder Teilnehmer sofort seine eigenen gesendeten Daten empfängt?
Es müsste also irgendwo eine Abfrage geben: "if IPAdr=EigeneIPAdr then IngoreData".

Hast du Virenscanner und Personal Firewall testweise ausgeschaltet? (beide können nämlich den Empfang von Daten verhindern)

@sx2008: Client und Server haben natürlich unterschiedliche IP-Adressen!

Ich vermute einen Fehler beim Anworten auf die Anfrage. Bei mir ist die Antwort so realisiert:

ABinding.SendTo(ABinding.PeerIP, ABinding.PeerPort, AData);
Wäre es möglich, dass bei Dir der PeerPort gecached wird und deshalb zeitweise nicht korrekt ist?