spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

... was ist daran wohl falsch?

Wenn jetzt das select eine -1 liefert, wird daraus ein 2^32-1 und das ist DEUTLICH größer als 1.

Wenn aber select einen Fehler gemeldet hat, werden auch die fd_sets nicht modifiziert und m_acceptSocket bleibt drin stehen, obwohl dort keine Daten anliegen.

Ergo: accept wird aufgerufen und blockiert logischerweise.

Bei mir gibt's einen select Fehler, weil der Client die Verbindung sofort nach dem Connect wieder schließt. Damit ist in der Liste ein ungültiger Socket, und select meckert.

Achso, die Auflösung ist natürlich:

Mom, imo ist ein Socket unter Windows ein unsigned int und für Fehler gibt es den INVALID_SOCKET Wert. Nur bei Linux (oder UNIX?) ist das ein int mit -1 als Fehlercode.
Unter Windows wird auch statt unsigned int SOCKET verwendet, was meiner Meinung nach extrem intelligenter ist als unsigned int oder int. Wenn man das ganze unter Linux kompiliert schreibt man einfach nur typpedef int SOCKET und kann wie gewohnt weitermachen.

Der Ergebnistyp der select Funktion ist sowohl unter Windows als auch unter UNIX ein int. Das ist auch gut so, weil Windows versucht bei den "kleingeschrieben" Funktionen der Winsock2 Implementation möglichst dicht am UNIX zu bleiben.

SOCKET_ERROR ist unter Windows einfach nur ein

Das hat also alles mit dem Datentyp, der für ein Socket verwendet wird, herzlich wenig zu tun. :roll:

edit: Das Biest heißt natürlich SOCKET_ERROR und nicht INVALID_SOCKET. Den gibt's zwar auch, und als int interpretiert wäre es auch -1, aber "::select" gibt ja keinen Socket als Ergebnis zurück. Da hab ich mich aufs Glatteis führen lassen, sorry.

Wenn ich in Codeblocks mit MinGW als Compiler bei SOCKET auf "Find declaration" klicke, finde ich in der winsock2.h:

Sieht für mich relativ Vorzeichenlos aus (Ja u_int ist als unsigned int deklariert und nciht als signed int). Und es deckt sich auch mit dem, was ich im Internet bisher über Sockets unter Windows gelesen habe.
Mag sein, dass Microsoft mal wieder was geändert hat, ob meine Version jetzt neuer oder älter ist weiß ich nicht, aber ich habe eine ziemlich aktuelle MinGW Version.
Deshalb macht es ja auch Sinn SOCKET statt u_int oder int zu benutzen. Dann kann es dir nämlich scheiß egal sein.

Schau nochmal genau hin: es geht um den Ergebnistyp der "::select" Funktion und nicht um den Datentyp, der für ein Socket benutzt wird.

Also ich hatte das Problem, dass ich die Clients immer mit einem Connection timeout rausgeflogen sind. Daher läuft das mit dem Accept bei mir in einem anderen Thread.

Zitat von »"$nooc"«

select() soll die gebräuchlichere variante sein...

Das sagt noch lange nichts darüber aus, was besser ist.