   Accepting multiple pending connections at once?
  Hey..Im current testing a server and 2 clients, after asking for connecting on both clients, select returns the listen socket on the read set, than I call acept on it..But than I have to repeat all that for the other pending connection that was alredy there..theres a way of accepting both clients, without querying for select again?(for a blocking accept)   
Hey..Im current testing a server and 2 clients, after asking for connecting on both clients, select returns the listen socket on the read set, than I call acept on it..But than I have to repeat all that for the other pending connection that was alredy there..theres a way of accepting both clients, without querying for select again?(for a blocking accept)Using standard sockets, I don't know that there is.  Is it so bad to have to call select again?  Normally, that's what you'll have to do as you can't guarantee clients will connect at the same time.   ;[quote name='Icebone1000' timestamp='1305898223' post='4813451']Hey..Im current testing a server and 2 clients, after asking for connecting on both clients, select returns the listen socket on the read set, than I call acept on it..But than I have to repeat all that for the other pending connection that was alredy there..theres a way of accepting both clients, without querying for select again?(for a blocking accept)Using standard sockets, I don't know that there is.  Is it so bad to have to call select again?  Normally, that's what you'll have to do as you can't guarantee clients will connect at the same time.[/quote]I was thinking on a real server, where thousands+ clients can be connecting and disconnecting all the time you know.;  The way the chat server I wrote worked was I had one thread that looped forever polling connections and if one was pending it added it the a List and than a worker thread handled the dispatching of messages including disconnections from clients.   ;Hey..Im current testing a server and 2 clients, after asking for connecting on both clients, select returns the listen socket on the read set, than I call acept on it..But than I have to repeat all that for the other pending connection that was alredy there..theres a way of accepting both clients, without querying for select again?(for a blocking accept)If you're using a POSIX implementation of Berkeley sockets, you can put your listen socket in non-blocking mode and call [font="Courier New"]accept()[/font] repeatedly to pull off queue connection requets until [font="Courier New"]accept()[/font] returns -1 and [font="Courier New"]errno[/font] is set to [font="Courier New"]EAGAIN[/font] or [font="Courier New"]EWOULDBLOCK[/font].  If you're using the WSA re-imagining of Berkeley sockets, you can use completion ports.Saving this single context switch will give you a minor performance improvement at the ten thousand new connection requests per minute level.  Consider if the extra logic is worth it for your application.   ;[quote name='Icebone1000' timestamp='1305898223' post='4813451']Hey..Im current testing a server and 2 clients, after asking for connecting on both clients, select returns the listen socket on the read set, than I call acept on it..But than I have to repeat all that for the other pending connection that was alredy there..theres a way of accepting both clients, without querying for select again?(for a blocking accept)If you're using a POSIX implementation of Berkeley sockets, you can put your listen socket in non-blocking mode and call [font="Courier New"]accept()[/font] repeatedly to pull off queue connection requets until [font="Courier New"]accept()[/font] returns -1 and [font="Courier New"]errno[/font] is set to [font="Courier New"]EAGAIN[/font] or [font="Courier New"]EWOULDBLOCK[/font].  If you're using the WSA re-imagining of Berkeley sockets, you can use completion ports.Saving this single context switch will give you a minor performance improvement at the ten thousand new connection requests per minute level.  Consider if the extra logic is worth it for your application.[/quote]He explicitly asked for a blocking socket solution.  I believe he realized, if it was non-blocking, he could get it to work.  Still, I think you what you save using non-blocking is extremely negligible, if anything.   ;I was thinking on a real server, where thousands+ clients can be connecting and disconnecting all the time you know.Use something like boost::asio, which gives you an event for each socket that connects.I would not recommend using select() for thousands of users anyway. I remember switching our message queue gateways from select() to events and CPU load went from a full core's worth to practically zero, with > 10,000 users per gateway.Btw: you could special case your select() loop; if the accept socket is readable, you immediately accept() and call select() again on only that socket, with a zero timeout; as long as there is a connection, keep accepting. However, if users connect/disconnect faster than they are sending packets or ticking the simulation (if there is one), your design might need re-thinking anywawy :-)   