Checking for server updates with TCP/IP without polling
Author
Sorry if this is a trivial networking question; I am making the jump from pure graphics programmer to starting on networking.
I'm looking to create a main server that handles messages such as basic chat. While its is quite obvious how to send/acknowledge chat sent to the server, I'm not sure how to update clients with chat sent by other clients. The only thing that comes to mind is to pull the sever every given interval with new chat that has occurred since the last poll.
Is there a better way to do this using TCPIP? Thanks!
In that situation, the server would send out the chat message to all the other clients. The client shouldn't have to poll the server for anything. Exact implementation details depend on the language and platform, but the server should be using asynchronous I/O of some kind.
An example using Boost::ASIO network layer. See the "Chat" section.
There's no polling, since everything is asynchronous.
There's no polling, since everything is asynchronous.
Author
I see, I was hoping to keep the server listening for connections, and having the client purely connecting to send and receive (and closing connection after). Thanks for the feedback.
There is huge overhead in setting up and tearing down a connection. Connections are typically persistent for the duration of a session. Especially in a game, anyone partaking in the game will have an open socket to the server (and the server will have one session per client).
Author
Hmm, Well for the game I'm maintaining the connections, but for the lobby client to create/join games ill have far too many connections. Is there really an alternative to breaking connections if ill have potentially 1000's of connections to the lobby?
Quote:Original post by skow
Hmm, Well for the game I'm maintaining the connections, but for the lobby client to create/join games ill have far too many connections. Is there really an alternative to breaking connections if ill have potentially 1000's of connections to the lobby?
Then use UDP - the connection-less protocol.
Thousands of connections are not necessarily the problem, if there's not much traffic going over them. Idle connections will just need a keep-alive signal once in a while.
Thousands of users in same chat room isn't practical anyway. On IRC, having 100 in same room leads to disasters if unmoderated.
But lobby server isn't necessarily same as chat server. Most such servers are partitioned to limit number of users, since thousands simply cannot talk at the same time in the same channel.
Author
Quote:Original post by Antheus
Then use UDP - the connection-less protocol.
Thousands of connections are not necessarily the problem, if there's not much traffic going over them. Idle connections will just need a keep-alive signal once in a while.
Thousands of users in same chat room isn't practical anyway. On IRC, having 100 in same room leads to disasters if unmoderated.
But lobby server isn't necessarily same as chat server. Most such servers are partitioned to limit number of users, since thousands simply cannot talk at the same time in the same channel.
Yeah, I was hoping to stick with purely TCP/IP. It wont be 1000's in a channel, but a a collection of channels with 1000's across the board.
Thanks for the feedback.
And perhaps more importantly, in modern OSes. TCP stack inefficiencies have been squashed over the past couple decades, partly thanks to DoS attacks which exploited them. A few thousand connections isn't very many, not when they're inactive.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement