Socket Error eeConnect

[Antigo]

Hi,
Ich hab ein kleines Netzwerk Problem.
Und zwar möchte ich eine Client Anwendung (Clientsocket) mit einer Server Anwendung (Serversocket) verbinden. Das klappt auch alles wunderbar aber jetzt hhabe ich einen seltsamen, reproduzierbaren Fehler entdeckt.

Zu Testzwecken hab ich Server und Client auf meinem Rechnen laufen lassen und mich auf Client Seite auf die IP 127.0.0.1 eingewählt. Soweit kein Problem. Dann hab ich versuchsweise die IP 127.0.0.2 versucht.
Jetzt hat er versucht sich zu verbinden und nach 5 Sek. hat mein Timeouttimer den Loginversuch per clientsocket1.close abgebrochen (Das mache ich so weil der Timeout des Sockets zu lange dauert). Dann hab ich mich 2 Sek später wieder auf die richtige IP eingewählt und erst sah alles gut aus. Nach ca. 15 sek. wird dann aber ein Socketerror ausgelöst. Die Fehlernummer ist 10065 und das ErrorEvent gibt eeConnect aus

Zitat von Delphi Hilfe:

Bei Client-Sockets bedeutet dieser Wert, dass der Server nicht gefunden wurde oder dass ein Problem auf dem Server das Öffnen der Verbindung verhindert. Bei Server-Sockets bedeutet dieser Wert, dass eine Client-Verbindungsanforderung, die bereits angenommen wurde, nicht beendet werden kann.

Es kommt mir so vor als wäre das ein verspäteter Error von dem ersten Login Versuch ins Nirvana. Allerdings kommt dieser Fehler wirklich nur dann wenn ich michunmittelbar nach den sinnlosen Login Versuch nach 127.0.0.2 wieder nach 127.0.0.1 einwählen will.
Mache ich danach nichts, kommt kein fehler. Logge ich mich direkt in 127.0.0.1 ein ohne es vorher im Nirvana zu versuchen ist die Verbindung auch stabil.

Kann sich das jemand erklären? Diese Sockets sind mir teilweise immer noch ein rätsel

mfg


PS:Ich benutz die Standart TClientsockets aus Delphi 7 keine Indys etc.

[Muetze1]

127.0.0.1 ist eine ganz spezielle IP die bei jedem Rechner die loopback Adresse darstellt und immer den lokalen Rechner anspricht. Dies ist nicht deine "richtige" IP Adresse. Wenn du nun als zu deinem anderen Rechner verbinden willst, dann musst du entsprechend den richtigen Hostnamen oder die richtige IP Adresse angeben. Eine IP Adresse 127.0.0.2 ist ungültig und existiert auch nicht.

Deine IP Adresse bekommst du z.B. in der Eingabeaufforderung mit dem Tool IPConfig heraus.

(Ich habe zwar immernoch keinen Text drauf, aber ich verweise schonmal auf www.standard-standart.de)

[Zacherl]

Was wird es auf der Seite geben?

[Antigo]

Zitat von Muetze1:

127.0.0.1 ist eine ganz spezielle IP die bei jedem Rechner die loopback Adresse darstellt und immer den lokalen Rechner anspricht. Dies ist nicht deine "richtige" IP Adresse. Wenn du nun als zu deinem anderen Rechner verbinden willst, dann musst du entsprechend den richtigen Hostnamen oder die richtige IP Adresse angeben. Eine IP Adresse 127.0.0.2 ist ungültig und existiert auch nicht.

Deine IP Adresse bekommst du z.B. in der Eingabeaufforderung mit dem Tool IPConfig heraus.

(Ich habe zwar immernoch keinen Text drauf, aber ich verweise schonmal auf www.standard-standart.de)

Ähm ich bin mir über die Bedeutung von IP Adressen durchaus im klaren

Ich weiss auch, dass es keinen Sinn gibt sich auf 127.0.0.2 einzuwählen, es geht mir einzig und allein darum herauszufinden, warum dieser Fehler auftritt und wie ich ihn vermeiden kann...

[Muetze1]

Ok, sorry, das hatte ich nicht richtig verstanden - aber du hattest es ja oben geschrieben. Gekonnt ignoriert, sage ich da mal.

Ansonsten ist das Verhalten der Sockets wirklich komisch, aber anscheinend wird beim Close der Socket nicht richtig geschlossen und der Thread wird trotzdem mit dem TimeOut informiert. Im Normalfall hängt er so lange in dem aufgerufenen Socket Connect Aufruf bis dieser durch TimeOut zurück kehrt. Da das Close den Socket als "closed" intern vermerken kann, kann er aber nicht die schon aufgerufene Funktion abbrechen, da er dort gerade in der WinSock drinne hängt.

Als Lösung würde ich folgendes Versuchen: Der TCustomWinSocket hat afair eine Eigenschaft mit dem Handle. Wenn du nun mit deinem eigenen TimeOut den Socket abbrichst, dann vermerke dir vorher dieses Handle. Bei der Exception dann vergleich, ob es dieses vermerkte Handle ist und ignoriere den OnError Aufruf komplett. Das wäre ein Vorschlag, in der Annahme, dass das Handle sich unterscheidet zwischen den Versuchen/Verbindungen. Wenn das Handle aber auf der Instanz von TCustomWinSocket basiert, dann wird es wohl nicht klappen. Naja, nur mal so eine Idee...

[Antigo]

ja das könnte ich mal probieren, danke für den tipp