Blacknull,

recvfrom() can be called from any and all threads. It doesn''t matter that you have only one port. If you are worried about thread synchronization just use a critical section. Critical sections are fast.

I rarely use recvfrom in my programs. Typically I use WSARecvFrom (Win32 specific function) with overlapped I/O.

To avoid your gateway problem (are you thinking NAT?) the easiest way is to just include a 4-byte IP address in the message. No big deal there.

Maybe I''m missing your point.

Regards,



Dire Wolf
www.digitalfiends.com

First of all, sending the IP address along in the packet does seem a bit dumb
With NAT, every connection gets a unique port, so you can tell different connections from the IP/port pair - that's how the TCP layer tells which packet belongs to which connection, so it can't be wrong.

Why do you want to use so many threads? It just unnecessarily increases the amount of system resources you use up (unless you got 70-100+ processors that is...
Just have any thread read a message from any client. You can use the IP address delivered by recvfrom(), and if you've got a sorted lookup array for all clients you can just do a binary search to get the client structures. You'll have to do that anyway (yes, there are ways of listening to packets from a specific IP address w/ UDP, but I don't think their overhead is worth it).

If you want to use threading consider that there are three different threading models (which I can think of right now, there are probably more):
- World partitioning. This really only applies to MMO games. The idea here is that you split your world into say 4 parts and have 4 threads where each thread handles one of the partitions. This is probably the simplest threading model and potentially the most efficient one too (because inter-thread issues are reduced to a minimum, thus reducing the pressure on caches and the memory bus)
- Worker threads. You have one thread which recvfrom()s from your UDP socket. When it gets a packet, it puts it into a queue, the request is dequeued by a worker thread. I really don't think this is a good approach, because you're doubling efforts. WinSock (or whatever the socket-implementation is) already implements a message queue, and you're just creating a second one, which means you've got more overhead.
- Free multithreading. Every thread recv()s from the same socket (or maybe from an I/O completion port or similar). When it receives a packet it rushes off to serve the request completely; when it's done, it recv()s again. Whether you send() update packets to players in those very same threads is up to you (I don't think it's a good idea as it could potentially open the door for floods). This model potentially includes one framework thread which occupies itself with time-based and non-player related events.

Generally I don't think that thread-bloating a program is a good idea, especially it's not a good idea for games. You just increase overhead for interthreadlocking, context switches and so on. The max. should really be the number of processors, and maybe 1,5-2x the number of processors if the threads might block or do costly I/O.

cu,
Prefect

One line of sourcecode says more than a thousand words.

Edited by - Prefect on August 20, 2001 1:36:25 PM