Client-Server Game Question

[magnificence7]

Ok, so this isn't exactly a C++ question, but I expect a certain group of people here that might have experience in certain areas. ;)
Now I have worked with sockets before. I only used the TCP/IP protocol and only for occasions where the client sends a request and the server sends back an answer.
Now I'm working on a simple online game where other people walk around in the world too. My idea is that people will get notified when others walk or take any other action. Anyway, I need a 'broadcasting' system. The server sends a message to the client. Now an idea was to maybe send a request every x milliseconds to request every players action, and anything else I need to be notified about. On the other hand, I don't know what's possible with the UDP/IP protocol and I know there is no connection established, and it is a good choice for performance/speed. Is there a way I can be notified without having to ask for it (sending a request), like for example, the server keeps track of which clients are logged in and whenever a client takes an action, the server broadcasts it to any nearby client.
Well, whatever will work best.

So can anyone answer my questions or give me a good idea?
Thank you.

[magnificence7]

BTW: I was thinking about this before, that maybe clients should notify each other, but it didn't really seem doable because I think every client has to open op a port on their router, right?

[Lv0f92yv]

One way (taking off on your broadcast idea) might be to have each client spawn two threads: One thread is its main thread (maybe user interface/display/etc, while the other listens for events sent from the server and receives events to send to the server from the main thread.

Whenever a client does something that other clients should know about, the listen/send thread is notified by the main thread about whatever action has occurred. The send/receive thread then notifies the server about what it's client has done, and the server relays that to all the clients connected. Each client will then receive that notification with their listening thread, and forward whatever is necessary to the main client thread.

There are probably better ways to do this, but I think this would work. Server side implementation of this would get a little more complicated, but shouldn't be a big deal unless hundreds of clients are connected.... For like 5/6 clients, a server running a couple threads waiting for input should do the trick. This topic came up in another thread, where someone had mentioned the idea of worker threads blocking on queues for a server with many clients: http://cplusplus.com/forum/general/39778/#msg215179

[magnificence7]

Ok, so can I do that with anUDP socket?
Can I receive without sending a message first?

[Lv0f92yv]

I am not sure if UDP is what you want to use here... I know many popular games use UDP protocol for this type of thing, so it may very well work.

I was thinking in terms of TCP, since this is what I have used before, but I don't know enough about either protocol to be sure.

Anyone?

[hanst99]

TCP isn't suitable for gaming, it can and will cause lags.

[quirkyusername]

TCP isn't suitable for gaming, it can and will cause lags.

TCP is slow but safe, UDP is fast but you have no guarantee that a message will ever get to its recipient. Therefore it is a good idea to use TCP for things like waiting on a new connection message, or basically sending any message which it is absolutely imperative arrives, and UDP for updates which will happen very often and which can be made up for if a message is lost somewhere. For example players will send messages to the server saying that they have moved to a new position over and over, but if one is missed you can make a close approximation to where they will be now given their previous position, direction and speed. Look into techniques like dead reckoning if this interests you.