I want to know who is using select() and what pitfalls they are encountering.

Im using select() in my server code (havnt gotten around to the client code yet ), I havnt run into any difficulties as of yet with the sockets code, but if my little game gets popular, my machine will probably crumble from all the for() loops

--LordKaT

I''ve been reading how if your code returns from select() with an indication that it should check the listen socket and it calls accept(), that accept() might block if the client which contacted the server dropped the connection in the interval between the server returning from select() function and getting to the accept() function.

I have not seen that problem, though I think it could be fixed with a check before accept()

--LordKaT

A check of what before accept()?

I''m using select(). I''ve never had any problem with it.

[Questions (STFW) | GDNet Start Here | GDNet Search | Forum FAQ | Google | Asking Smart Questions ]
[Docs (RTFM) | MSDN | SGI''s STL | OpenGL | File formats]
[C++ Must Haves (RTFS) | MinGW | Boost | Loki | FLTK | SDL ]

Stolen from Magmai Kai Holmlor, who held it from Oluseyi, who was inspired by Kylotan...

quote:

---

Original post by Fruny
I''m using select(). I''ve never had any problem with it.

---

It''s not like you ordinarily would. It''s just that there exists a situation where a busy server could miss a client between select() and accept() if the client does something related to an RST (I''m not certain what that is).

Let''s say you''re running a game server where most clients have logged in and the number of new clients logging in is sporadic. If someone deliberately created a client to do what I am talking about, your server would block on accept() until another client connected.

A rare case? Sure. A possible exploit? Yes.

This problem is described in Unix Network Programming, part 1 section 15.6.

quote:

---

The fix for this problem is to

1. always set a listening socket nonblocking if we use select to tell us when a connection is ready to be accepted, and

2. ingore the following errors on the subsequent call to accept: EWOULDBLOCK (for Berkeley-derived implementations, when the client aborts the connection), ECONNABORTED (for Posig.1g implementations, when the client aborts the connection), EPROTO (for SVR4 implementations, when the client aborts the connections), and EINTR (if signals are being caught).

---

[Questions (STFW) | GDNet Start Here | GDNet Search | Forum FAQ | Google | Asking Smart Questions ]
[Docs (RTFM) | MSDN | SGI''s STL | OpenGL | File formats]
[C++ Must Haves (RTFS) | MinGW | Boost | Loki | FLTK | SDL ]

Stolen from Magmai Kai Holmlor, who held it from Oluseyi, who was inspired by Kylotan...

Exactly. Thank you for typing out the text which made me bring up this issue in the first place.

Now, although I have been programming for a long time, I haven''t been using sockets much at all until two weeks ago. So, in Windows, how do we make that socket nonblocking? Stevens is using fcntl, but I am not sure if that is the way it is done in Windows.

set the timeval in select() to 0 instead of using NULL.

(just out of curiosity, why didnt you just ask how to make a socket nonblocking in the first place?)

--LordKaT