Hello everybody, I started creating an UDP server-client system for my game, and right now things are going pretty good, but they are also getting more and more complicated. Right now, what i do is create a new thread for listening both on the client and the server. The thread is created when the server is activated, destroyed when its stopped (Which can be done at any moment during gameplay). But now i''m starting to wonder how to do this without multithreading.... It would simplify things, wouldnt have to deal with thread synchcronisation or creating/destroying threads. My first question is, how do you implement this with select... Second question is..... Is it really so bad to do that without multithreading? Any disadvantages?

Well, you can''t use select unless you thread. It is blocking and would prevent the server from running unless there was netowrk traffic. That would, at best, limit your server frame rate to traffic flow.

Also, if you start having slow frame rates on the server, you could start losing packets because it can''t read the network fast enough.

If your creating an MMP server, thread the read portion of your network layer. IMO you should always thread both the read and the write.

Thread synronization is not a big deal. Once you''ve worked with threads enough, you will start to understand how to do it effectively.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

select() only blocks if you tell it to block. The last parameter of select is a pointer to a timeval struct. If you make this pointer NULL, it will block until one of the FD''s you passed in is ready, however, if you pass in a valid timeval struct, it will wait that amount of time before returning, and if you pass a timeval struct with 0 seconds and 0 microseconds, it will not block at all.
Using select() (and not threads) has the advantage of less context switching, which takes time. It''s not bad at all to not use threads, especially in a single processor system.
select() is really quite simple. Just check beej''s guide which can be accessed from the multiplayer articles on this site. You would just use select() once per game loop to check for incoming data, and if you have buffered outgoing data, check if it can be sent.

Your right. I never use that feature so I kind of forgot about it. But context switching takes no more time than calling select(). We''re not talking about process context switching here, it''s thread context switching we''re talking about. Blocking a select() statement is much more efficient than running through it all the time. There is no context switch if the select is blocking, which it will do most of the time, unless it''s an MMP server your making.

I get somewhat jaded when I hear people saying that multi-threading is bad or hard. I deal in the MMP universe as well, where we have multi-processor machines to run on all the time. My use of threading on our servers has made them much more efficient than being single threaded. Response time is higher, and CPU utilization is much better than running multiple processes on the same box.

If done right, threading is no more expensive, and often more efficient than single threading an app. And you can take advantage of multi-processor machines.