Hello guys. I was wondering is there any tutorial describing how to make network support in games? Like what should server send and receive and in what order? Clients?
I guess best way is to make net_events like in SDL: server should translate incoming packets into events, then handle them, generate events for clients and send them back.
Server and clients should have queue of events (like in SDL)...but i'm not sure if it's the best solution.
0
Network programming strategies. Any tutorial?
Started by dEgle, Nov 03 2012 02:14 PM
6 replies to this topic
Sponsor:
#2 Moderators - Reputation: 3371
Posted 03 November 2012 - 05:54 PM
There are as many networking systems as there are game genres, because each kind of game needs different compromises in data model richness, accuracy, throughput management, and latency compensation.
Yes, it's totally fine to keep a queue of events to send on one end, send them all as one packet every so often, and then put them in a queue of events to dispatch/deal with on the receiving side. Many games work like that. If you're using TCP, beware that you have to put a length field before each "packet" that you send, because the TCP connection may/will split your send() calls into multiple recv() calls and/or combine multiple send() calls into a single recv() call.
Yes, it's totally fine to keep a queue of events to send on one end, send them all as one packet every so often, and then put them in a queue of events to dispatch/deal with on the receiving side. Many games work like that. If you're using TCP, beware that you have to put a length field before each "packet" that you send, because the TCP connection may/will split your send() calls into multiple recv() calls and/or combine multiple send() calls into a single recv() call.
enum Bool { True, False, FileNotFound };
#3 Members - Reputation: 131
Posted 04 November 2012 - 04:40 AM
There are as many networking systems as there are game genres, because each kind of game needs different compromises in data model richness, accuracy, throughput management, and latency compensation.
Yes, it's totally fine to keep a queue of events to send on one end, send them all as one packet every so often, and then put them in a queue of events to dispatch/deal with on the receiving side. Many games work like that. If you're using TCP, beware that you have to put a length field before each "packet" that you send, because the TCP connection may/will split your send() calls into multiple recv() calls and/or combine multiple send() calls into a single recv() call.
Actually I'm using UDP, so event can fit in one packet. Thanks anyway:)
#4 Moderators - Reputation: 3371
Posted 04 November 2012 - 10:46 AM
Actually I'm using UDP, so event can fit in one packet.
In that case, you want to fit all events from the queue in the single UDP datagram each time you send a datagram.
Set a send rate -- 5 times a second, 20 times a second, whatever suits your game -- and stuff all the events into a single datagram for each packet you send. If there are no events, still send a packet, so you can detect connected vs disconnected users, do time management, detect dropped packets for re-tries, etc.
enum Bool { True, False, FileNotFound };
#5 Members - Reputation: 131
Posted 04 November 2012 - 01:37 PM
I guess it's best idea to reduce traffic when sending events from server to each clients and vice versa:)In that case, you want to fit all events from the queue in the single UDP datagram each time you send a datagram.
Will it work if i send events from client to server each frame (if there are any events) and server will send events to clients each frame, so there will be no exact rate?Set a send rate -- 5 times a second, 20 times a second, whatever suits your game -- and stuff all the events into a single datagram for each packet you send. If there are no events, still send a packet, so you can detect connected vs disconnected users, do time management, detect dropped packets for re-tries, etc.
That way I will have to have ping-pong requests to measure latency, disconnected palyers, etc.
#6 Moderators - Reputation: 3371
Posted 05 November 2012 - 12:03 PM
Will it work if i send events from client to server each frame (if there are any events) and server will send events to clients each frame, so there will be no exact rate?
That way I will have to have ping-pong requests to measure latency, disconnected palyers, etc.
Will it work? Probably, if you implement it right :-) The main challenge I can see with that is detecting whether a packet was dropped. If I send a packet to you, and there's no guaranteed stream of packets back, then I don't know whether you got it or not if I don't hear back from you.
enum Bool { True, False, FileNotFound };
#7 Members - Reputation: 131
Posted 05 November 2012 - 01:41 PM
I meant if it is a right thing to implement:)
In case of lost packets with events...players might be teleporting;-)
For example if i send datagram with map data of file parts i will definitely number these packets, so if there is a non stable connection client can ask to resend right packet.The main challenge I can see with that is detecting whether a packet was dropped. If I send a packet to you, and there's no guaranteed stream of packets back, then I don't know whether you got it or not if I don't hear back from you.
In case of lost packets with events...players might be teleporting;-)
