Windows Socket error???

ralfi · Beiträge: 153

Nach dem mein Programm ca 20 min. läuft, kommt folgende Fehlermeldung:

Windows Socket error: Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war(10055), on API 'connect'

Was ist das und wie kann ich das verhindern?

MSCH · Verfasst: Sa 19.07.03 22:43

so wie es aussieht, schließt du den socket nicht. ein doppeltes connect dürfte die ursache sein.
poste mal etwas code, leider ist das orakel auf urlaub. :-)

grez
msch

Nemesis II · Beiträge: 49

Hallo, auch wenn die Frage Jahre alt ist, den Fehler gibts immer noch.

Bei mir kommt dieser Windows Socket Error (10055), ca. nach 2,5 Stunden. Ein Timer versucht ständig eine Verbindung zum Server herstellen, solang diese besteht, wird der Timer deaktiviert. Aber nach 2,5 Stunden erfolgslosen Verbindungsaufbau, kommt dieser Fehler. Ich hab zwar versucht nach jedem Fehlschlagen den Socket zu schließen aber es funktioniert trotzdem nicht. Hier der Code:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

procedure TForm1.Timer1Timer(Sender: TObject);
begin //Zeitkonstante 5 Sekunden
CS1.Open;
CS2.Open;
end;

procedure TForm1.CS1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS1.Close;
end;

procedure TForm1.CS2Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS2.Close;
end;

Danke schon mal für die Antworten!

Narses · Verfasst: Di 16.01.07 20:56

Moin!

Nemesis II hat folgendes geschrieben:

auch wenn die Frage Jahre alt ist, den Fehler gibts immer noch.

Und es ist die gleiche, jahrealte Ursache: Versuch, einen offenen (oder zumindest in Aktion befindlichen) Socket zu öffnen.

Nemesis II hat folgendes geschrieben:

Ein Timer versucht ständig eine Verbindung zum Server herstellen,

Das Konzept dahinter ist nicht so schlau.

Mach es besser so:

CS1.Open; und CS2.Open; keine Timer!
Im OnError der Sockets den betreffenden schließen (sicherheitshalber) und einen Timer starten (für jeden Socket einen eigenen!), der ein erneutes Open auslöst, aber sich nach dem Open wieder deaktiviert!

So ist nur in der Fehler-Phase je ein Timer für den Socket aktiv und nicht dauerhaft.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Nemesis II · Beiträge: 49

Danke für die schnelle Antwort, also ich hab das jetzt so realisiert:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:

procedure TForm1.FormCreate(Sender: TObject);
begin
CS1.Open;
CS2.Open;
end;

procedure TForm1.CS1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS1.Close;
Timer1.Enabled := true;
end;

procedure TForm1.CS2Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS2.Close;
Timer2.Enabled := true;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
CS1.Open;
Timer1.Enabled := false;
end;

procedure TForm1.Timer2Timer(Sender: TObject);
begin
CS2.Open;
Timer2.Enabled := false;
end;

Narses · Verfasst: Di 16.01.07 21:14

Moin!

Ja, genau so meinte ich das.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Nemesis II · Beiträge: 49

Hallo,

leider musste ich feststellen, dass dieses Problem weiterhin besteht.

Mir ist aufgefallen, dass dieses Programm langsam den Arbeitsspeicher füllt, von rund 6MB auf 11MB, dann kommt der Fehler, in dem Zeitfenster von 2,5 Stunden.

Würde es bringen die Resourcen der Sockets bzw. des Programms, nach jeder Fehlverbindung, frei zu geben?

Danke im Voraus

Narses · Verfasst: Fr 19.01.07 16:21

Moin!

Nemesis II hat folgendes geschrieben:

leider musste ich feststellen, dass dieses Problem weiterhin besteht.

Mir ist aufgefallen, dass dieses Programm langsam den Arbeitsspeicher füllt, von rund 6MB auf 11MB, dann kommt der Fehler, in dem Zeitfenster von 2,5 Stunden.

Hm, grad nochmal nachgesehen:

markieren

Quelltext

1:	WSAENOBUFS = (WSABASEERR+55);

Scheint, als ginge der WSA die Luft aus, bei deinem TCP-hammering-"Angriff"...

Nemesis II hat folgendes geschrieben:

Würde es bringen die Resourcen der Sockets bzw. des Programms, nach jeder Fehlverbindung, frei zu geben?

Nein, wenn überhaupt, dann den Prozess beenden und neustarten.

"Muss" das denn so konzeptionell sein?!? :roll:

Warum nicht einfach den Server anpingen und erst wenn er reagiert in "vernünftigem Zeitfenster" (=max. alle 5 Minuten) einen TCP-Connect versuchen? :?:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Nemesis II · Beiträge: 49

Hi, nochmals danke,

ist dieses Connect nicht das Gleiche wie das Anpingen?
Der Client versucht die Verbindung zum Server aufzubauen, und wenn es nicht klappt kommt der Fehler, wird denn beim Anpingen etwas anderes gemacht?

Narses · Verfasst: Fr 19.01.07 16:41

Moin!

Nemesis II hat folgendes geschrieben:

ist dieses Connect nicht das Gleiche wie das Anpingen?

Nein, hier ist ein Beispiel für einen API-Ping.

Nemesis II hat folgendes geschrieben:

Der Client versucht die Verbindung zum Server aufzubauen, und wenn es nicht klappt kommt der Fehler, wird denn beim Anpingen etwas anderes gemacht?

Ja, ein Ping prüft nur die Erreichbarkeit des Servers, während ein TCP-Connect ein Versuch ist, eine gesicherte Punkt-zu-Punkt-Verbindung aufzubauen. Dafür werden WSA-intern Resourcen benötigt.

Allerdings kann man einen Ping und einen TCP-Connect auch nicht direkt vergleichen:
Ping -> prüfen, ob ein Host per IP erreichbar ist
TCP-Connect(-Versuch) -> prüfen, ob ein Dienst auf einem bestimmten Port des Hosts erreichbar ist

Vielleicht versuchst du einfach mal zu beschreiben, was du vor hast; dann wäre es möglicherweise einfacher, nach Alternativen zu suchen.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Nemesis II · Beiträge: 49

Das Programm stellt eine Verbindung zum Server her, und verschickt Daten in jeder Form hin und her. Das Problem dabei ist, dass dieser Server nicht 24h lang online ist, der Client ebenfalls nicht. Und eben deswegen soll der Client ständig versuchen die Verbindung herzustellen.

Aber das mit dem Pingen versuche ich jetzt mal, falls ich Probleme habe melde ich mich nochmal, in einem neuen Beitrag!

Ciao

Nemesis II · Beiträge: 49

gibts auch die Möglichkeit diesen Buffer in der WSA auf null zu setzen?

Ich werde bei der Suche nicht fündig!

Please Help

Narses · Verfasst: Sa 20.01.07 16:33

Moin!

Nemesis II hat folgendes geschrieben:

gibts auch die Möglichkeit diesen Buffer in der WSA auf null zu setzen?

AFAIK nicht.

Du kannst wie hier beschrieben natürlich die Betriebsparameter des TCP-Moduls prima verfummeln, wenn du nicht ganz ganz genau weißt, was du da tust.

Aber ich schätze einfach mal, dein Konzept ist das Problem. Vermutlich wird nur ein anderer Ansatz das "Problem" lösen... :nixweiss:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Nemesis II · Beiträge: 49

Hallo, also es funktioniert alles!

Soweit ich mitbekommen hab, begrenzt Windows das Öffnen der Sockets, auf 4000 stück (meine Schätzung).

Ich hab einfach ein test programm geschrieben, welches die Fehlverbindungen zählt, ich lasse 2 Sockets gleichzeitig aufmachen, so wird dieser Puffer schneller voll. Zuvor habe ich versucht bei jedem SocketError, diesen Socket zu schließen, und wieder aufmachen. also:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:

procedure TForm1.FormCreate(Sender: TObject);
begin
CS1.Host := myhost;
CS2.Host := myhost;
CS1.Port := myport1;
CS2.Port := myport2;
CS1.Open;
CS2.Open;
end;

procedure TForm1.CS1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS1.Close; //achtet auf diese Zeile, denn sie war das Problem
CS1.Open;
end;

procedure TForm1.CS2Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode := 0;
CS2.Close; //achtet auf diese Zeile, denn sie war das Problem
CS2.Open;
end;

ok, alles schön und gut, aber seltsamer weise, hat das Programm den Socket nicht geschlossen und diesen WSA Buffer voll laufen lassen. Diese besondere Zeile habe ich durch diese ersetzt:

markieren

Delphi-Quelltext

1:	CS1.Socket.Close;

bzw.

markieren

Delphi-Quelltext

1:	CS2.Socket.Close;

Auf meine Schätzung von 4000 Sockets in der WSA, bin ich gekommen indem ich die Fehlverbindung gezählt habe, bei beiden Sockets waren es ca. 1980 Fehler, also insgesamt fast 4000, danach kam dieser Fehler:

Windows Socket error: Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war(10055), on API 'connect'.

Im Internet habe ich rausgefunden, dass es eine Möglichkeit gibt diesen Buffer in der Registry zu verändern, aber wozu, wenn es auch schöner geht

Danke an Narses für die Unterstützung, und ich hoffe diese Lösung wird jemanden helfen, da ich 2 Wochen dafür gebraucht hab, um weiter programmieren zu können.

Narses · Verfasst: Fr 26.01.07 17:34

Moin!

Das würde ja bedeuten, dass bei einem Verbindungsfehler und einem anschließenden erneuten Versuch ein neues Socket-Handle von der WSA angefordert würde...

Hmm... das schau ich mir nachher noch mal im QT der ScktComp genauer an (leider grad keine Zeit)...

Nemesis II hat folgendes geschrieben:

Hallo, also es funktioniert alles!

Fein!

Respekt, dass du trotzdem noch eine Lösung gefunden hast. :zustimm:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme