TSocketConnection hängt, wenn man Netzwerkkabel entfernt...

[alzaimar]

Na ja, irgendwie logisch, das das nicht gut geht.... Aber das Teil hängt einfach, anstatt irgendwann mit einem Error zurück zu kehren. Ich warte ca. 5 Minuten.... Ist das ein Bug oder ist das ein Feature?

Muss man damit leben, das TCP/IP sich u.U. einfach aufhängt? Oder ist das eine Macke der SocketConnection.

Hat jemand Erfahrungen damit?

Die Geschichte geht so:
Wir haben eine nette 3-Tier-Anwendung. Fremdprogrammierer sollen nun auf die Mittelschicht zugreifen. Da z.B. VB keine Socketconnection kennt, habe ich einen DLL-Wrapper geschrieben. Einer der Programmierer verlangt nun (zu Recht), das die DLL absolut bullet-proof ist, und max. 10 Sekunden warten soll (Die normale Response-Zeit liegt bei 200-500ms). Na ja, kann man über Threads lösen, oder gibt es auch einen richtigen Weg? Um die SocketConnection komme ich derzeit nicht herum, obwohl mittelfristig auch eine andere Lösung in Frage käme...

Ick hab ich heut sowat von blamiert, als ich die DLL demonstriert habe, und dieser Sack (netter Kerl und echt fähig) dann das Netzwerkkabel rausnahm und sagt: Typischer GAU... Und nu?.... Alter Schwede :oops:

[alzaimar]

*push*

[Balu der Bär]

Zitat:

Muss man damit leben, das TCP/IP sich u.U. einfach aufhängt? Oder ist das eine Macke der SocketConnection.

Ich weiß es nicht genau, aber es kann auch sein das sich die Verbindung nicht "aufhängt" sondern das Socket einfach wartet bis die Verbindung wiederhergestellt werden kann...

[Dj_Base]

Zitat:

Zitat von alzaimar

Muss man damit leben, das TCP/IP sich u.U. einfach aufhängt? Oder ist das eine Macke der SocketConnection.

Entweder ist es so, dass die Klasse darauf wartet, die Verbindung wieder aufzunehmen, oder sie ist halt etwas schlampig programmiert und kommt mit einem plötzlichen Verbindungsverlust nicht zurecht (was ich allerdings als eher unwarscheinlich einstufe) ...

Gruß,
Dj_Base

[Koloss]

Ich greife das Thema wieder auf, nutze Delphi2010 mit TSocketConnection und habe gemau das selbe Problem! Gibt es dazu eine Lösung?

Das Programm hängt sich bei Connection.Connected := False auf.

[mjustin]

Kann man mit einem Netzwerkmonitor die Verbindung noch sehen (netstat, TCPView...)?

Der Default-Timeout des Betriebssystems könnte so hoch sein dass die Fehlermeldung erst nach längerer Zeit erscheint. Ich habe aktuell keinen Link zu einem technischen Artikel, aber man kann ihn entweder systemweit abfragen oder setzen.

Ferner würde ich einfach mal den Debugger anwerfen und in Detail nachverfolgen, wo das Programm hängt.

Passender Stack Overflow Artikel:

https://stackoverflow.com/questions/...nnection-hangs

[Koloss]

Das Programm läuft noch aber er hängt eben bei connection := False. Auch wenn ich connection.Free oder Clientdataset.close hängt es. Ich kann da nichts weiter debuggen, ich komme da nur in das CPU Fenster.

Kmischerweise bei einen anderen Programm mit der selben Verbindung dort schiebe ich aber weniger Daten hin und her.

Code:

    try
      if SocketConnection.Connected then
      begin
        SocketConnection.Connected := False;
        Clientdataset.open;
      end;
    except
      SocketConnection.Connected := False;
      Clientdataset.close;
    end;

[mjustin]

Zitat:

Zitat von Koloss (Beitrag 1350576)

ich komme da nur in das CPU Fenster

Projekt Debug-DCUs kompilieren, Bibliothekspfade checken, nochmal versuchen. Der Sourcecode ist dabei :)

p.s. eventuell muss die MidasLib Unit anstatt MIDAS.DLL eingebunden werden.

[Koloss]

Code:

procedure TDispatchConnection.DoDisconnect;
begin
  if not VarIsNull(AppServer) then
    SetAppServer(NULL);
end;

Später dann im assembler Code(Unit System) schmeißt es ihm hm... das ist leider schon zu tief unten. Darin sehe ich keine lösung.

Witzigerweise hat er es einmal korrekt gemacht. War wohl zufall.

[mjustin]

Zitat:

Zitat von Koloss (Beitrag 1350585)

Code:

procedure TDispatchConnection.DoDisconnect;
begin
  if not VarIsNull(AppServer) then
    SetAppServer(NULL);
end;

Später dann im assembler Code(Unit System) schmeißt es ihm hm... das ist leider schon zu tief unten. Darin sehe ich keine lösung.

Witzigerweise hat er es einmal korrekt gemacht. War wohl zufall.

Einfach den Code der in SetAppServer steht lesen, weiterverfolgen, und an sinnvollen Stellen Haltepunkte setzen. So umgeht man die Assemblerwüste.

[Koloss]

Was bringt mir das? Sollte ich jetzt Delphi umprogrammieren?

[mjustin]

Zitat:

Zitat von Koloss (Beitrag 1350660)

Was bringt mir das? Sollte ich jetzt Delphi umprogrammieren?

Nur die Stelle wo das Timeout herabgesetzt werden muss. DataSnap verwendet Indy. Ob alle Quelltexte mitgeliefert werden weiss ich nicht, aber nach diesen Informationen kann man in neueren Versionen von Delphi auch neuere Versionen von Indy benutzen und DataSnap mit diesen neu kompilieren.

(Da so etwas auch daneben gehen kann, würde ich es vermeiden, und Experimente nur nach einer Datensicherung machen).

Man kann natürlich auch einen Bugreport erstellen, falls noch keiner zu diesem Problem existiert. Falls einer existiert, enthält er eventuell weitere Hinweise oder Workarounds.

[Koloss]

Ich habe den Client unter Delphi XE10 getestet und das selbe Problem tritt auf. Also eine neuee Indy-Version(Delphi 10 hat mit sicherheit eine neue Indy Version) hilft leider nicht.

Auch das setzen eines Timeouts bringt leider nichts:

Code:

    
    SocketConnection.ReadTimeout := 100;
    SocketConnection.ConnectTimeout := 100;

Es reicht auch die Netzwerkverbindung zu deaktivieren im Windows.