multiplayer (and LNet)

[laggyluk]

Anyone has experience with lnet library and udp?
I just got to implementing multiplayer part of my game project. And that's a first time I'm working with udp
Game architecture is event/message based so I had almost no problem with sending input through network to the 'server' part and controlling the actor. Which feels pretty good after going through all that event hassle ;p
Now, every frame input state is sent to server. I'm pretty sure I should drop packets that are older than last one received. But is this info encoded somwhere in the packet header or should I add 'frame stamp' my self?
And other thing, can server/sending socket get 'overflown' with send/receive requests?

[SilverWarior]

Anyone has experience with lnet library and udp?

No I'm afraid that I don't have direct expirience with mentioned library.

Now, every frame input state is sent to server. I'm pretty sure I should drop packets that are older than last one received.

If as an input state you mean which keys are pressed and mouse position then you definitly should not drop any packets. Droping packets in such scenario could lead to dropping information about player pressing certain button which would afect actor movment and its actions.
For instance: Player presses Left arrow button three times which is sent to server by three seperate packets and you discard one becouse newer packet has arrived before older was processed. This would result in server registering only two Left arrow key presses instead of three.
But if you are sending current state (actor position, actor actions, etc.) then you probably might get away with dropping of packets as you only require newest game state.

Also if you are using sending input states to server using of UDP might not be best idea. Why? UDP protocol does't have packet deliver confirmation system built in like TCP/ip does. So it is posible that some UDP packets get los or damaged in transit. This could lead to unexpected behavior.
So for sending input states it would be better to use TCP/IP becouse the built in delivery confirmation system will make sure that the packet is delivered intact (the packet will be automatically resent if necessary) and finally it will raise error message if the packet can't be sucsessfully delivered. And yes becouse of this delivery confrimation system TCP/IP does require more network bandwich.

I have seen a few games which actually use combination of both TCP/IP and UDP at the same time. Most data is sent through UDP to lower network bandwich. But at regular intervals whose purpose is for clinet/server synchronization they use TCP/IP becouse with it they can verify that data reached all clients sucsessfully.

[Super Vegeta]

What kind of connection to use and how to send your data depends quite much on what kind of game are you writing.

TCP is a nice protocol, because it makes sure that no data is lost, and that it arrives in order. API-wise, it is quite often represented simply as a stream of bytes, with all the packet-related hassle hidden from the programmer. TCP is connection-based: hosts must first establish a connection, and then they exchange data over it. Should the connection be lost, they will try to reconnect, which may take some time. Also, checking whether the packets are all in order also introduces some overhead.

UDP, on the other hand, is connectionless - you just hurl packets out into the net and hope they will reach their destination. There is no guarantee packets won't be lost nor will they arrive in order - so yes, you must include your own frameno/timestamp data somewhere in the packet. But because UDP is much simpler than TCP, it doesn't have that much overhead and is usually much faster.

So, regarding the type of game you're writing:

• With turn-based games, you could even go for TCP - most of the time the players will be waiting for their turn, and unless you incur some kind of turn length limit, a loss of few seconds because of packets resend/sort or reconnecting won't really matter.
• With some kind of RTS, a good choice is going for UDP and simply postponing executing player actions. When a player issues an order to the unit, you keep it in memory and postpone its execution for X game cycles. Unless latency is bad, the other players should receive this info before the scheduled game cycle, so everything will be perfectly synchronised. You can check packets dropped simply by requesting a delivery report on each packet and resending it if no report arrives in some amount of time.
• With some fast-paced games like shooters, things start to get tricky. If you plan only on local play, then yeah, you could go with sending input states every frame and only advancing the game once all players send their data. But on the web, you have latency, packets dropping and all that stuff. So it's simpler to just send state changes to the server and other players, and simply try to calculate as much as possible client-side. This article explains some quirks related to networking in fast-paced environments.

Obviously I'm no expert, since I haven't written much network code, but well, that's what I know. Hope you'll find my answer useful.

[laggyluk]

It's gonna be fast paced shooter (with Mass Efect 3 multiplayer mode as huge inspirration so tcp is not an option, maybe useful for chat or sth but not for gameplay. I started with sending input because it was a simplest step but as SilverWarrior mentioned it's not gonna do because dropping some packets will break the gameplay. I guess I'll have to pack world state in a packet like that steam article suggests.

[phibermon]

Your networking model sounds similar to mine - synchronization of actor properties using thread safe messages by using the network connection as a message relay. I'm currently using both TCP and UDP for communication. Individual properties are marked as either 'critical' or not along with a priority. critical, low priority messages through TCP (game state control, player chat etc) non-critical, high priority messages through UDP (rotation/heading without projectiles) and a blend between them for all other things. You can do packet confirmation on critical messages sent thru UDP for both speed and reliabilty but not bother with confirmation for things that don't really matter or would otherwise quickly get superseded.

For example for the position of a player, you can send one critical update to the position each second and inbetween those as many non-critical updates as the bandwidth allows for. So you could theoretically only get the critical update each second. Then you can use prediction combined with lerping like Quake3 net code etc to make the motion seem smooth for other players.

The nice thing about this is that marking a packet as non-critical / low-priority allows you to dump it or move it down the queue when a new critical/high-priority message comes in for sending. It's a total win to implement as theoretically your stream of messages could suffer such disruption anyway over UDP, all you're doing is juggling to squeeze out the real-time performance factor.

accurate timing sync + timestamps are critical for the setup, I recommend that you make timestamps an inherent part of your message structure. I connect my server messenger to my client messenger internally without networking and introduce artificial delays to the pumping of the queues and random message drops in order to simulate something approaching an unreliable internet connection. If you do this then your net code is no longer important, you can do the hard part of dealing with sync/delay in your own ecosystem and when it's done, just stream your messages through whatever TCP/UDP you fancy and job done.

To put simply, the networking code in this context becomes a message relay with a fast,unreliable path and a slower,reliable path. You could just use UDP and have a system for re-transmitting lost packets, and re-ordering them and while this can be faster than TCP in some scenarios, that is the fundamental difference between the two, TCP is basically UDP with packet re-transmission and re-ordering. There's no performance hit at all to using both TCP/UDP and the TCP path means any UDP packet reliabilty code can be non-existant or just very simple.

[laggyluk]

thanks for some ideas working on this feels refreshing