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.
Network programming strategies. Any tutorial?
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.
Author
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:)
Actually I'm using UDP, so event can fit in one packet. [/quote]
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.
Author
In that case, you want to fit all events from the queue in the single UDP datagram each time you send a datagram.
I guess it's best idea to reduce traffic when sending events from server to each clients and vice versa:)
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.
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 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. [/quote]
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.
Author
I meant if it is a right thing to implement:)
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.
In case of lost packets with events...players might be teleporting;-)
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.
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.
In case of lost packets with events...players might be teleporting;-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
