One thing you could maybe try, though I''m still working this out myself, is have the server create a new thread for each client connection. Whenever a message is recieved from a client, data is updated, and the server sends back the updated data.

The way my architecture is currently laid out, the server runs a recursive frame move method within a seperate thread. Whenever a client sends data (each frame move they send their updated state), the server updates it''s data, sends back a reply with it''s current data (say for all players) and goes back to happily running it''s recursive function. I have a large number of threads running with critical sections and mutexes all over hell''s half acre to keep everything in sync, but up to this point it seems to be working well.

This is a base look at it, but it should give you something to start with. If you want an in-depth look at designing network code for games, you may like to pick up a copy of Advanced 3D Game Programming with DirectX 9.0 by Peter Walsh. He has a whole chapter on the intricacies and issues of working with sockets and how to overcome them.

Permafried-

I have designed mine (UDP) to use a single thread to recv and a single thread to send, both for the server and client. The low level network stuff is wrapped up in a network class so that the user needn''t worry about critical sections/mutexs or local loop back if the app is both a server and client. The interface between the app and the network is done via priority queues using user supplied packets (destination, ACK, priority, msg, size). Similarly messages are recved via a priority queue.

SoulSpectre.

hi everyone again, i have some questions...

that is my new architecture:
(everything in a single thread)(UDP)
1. recv info ->while(!done){ if(!my_recv()){ done } } <- store info
2. sort info
3. send it back to everyone

what you think about ???

new question.. how wuld you send a "shot" with tcp or udp ?? with tcp i wuld be slow and with udp it isnt right anyway... well i wonder how to do this stuff ..


thx for help everyone.. i hope you wuld help me this time

edit:

about creating a thread for every client... can someone post some code ? .. i wuld like to see, what it looks like

[edited by - Wickeeed on June 9, 2004 3:35:37 AM]

please don''t create one thread per client. Kills scalability.

but just to actually answer the question you just create a thread and have the thread parameter be whatever information is needed to talk to the client. TCP this would be the socket for that client, UDP would be the address info structure.

however w/ UDP you have no idea who it is you are receiving from so you cannot have a thread that is the client state and read only from that client.

If you are going the thread route, use a work queue style implementation. read data, place in work queue, threads see theres work to be done, one gets the data nd works on it.

OK, this seemed as good a place as any to pop a little question that''s been bugging me for some time - how well do NAT-enabled routers handle UDP? As far as I can see, the user would need to manually forward incoming packets on your game''s port to their gaming machine in order to play online, vs. a TCP stream that gets automagically handled. This wasn''t a problem when it was only geeks that had NAT devices sitting between them and the internet, but now a lot of people have routers sitting between them and teh intarweb.

Good cause for using TCP? (assuming that your game is aimed at a diverse audience, who won''t all be networking gurus).