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

*push*

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...

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

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.

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

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.

markieren

Code:

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

Zitat von Koloss:

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.

markieren

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.

Zitat von Koloss:

markieren

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.