32 ms·

RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in

RUDP sounds very weird... why would you use it instead of TCP? At a glance, it looks like the only difference is RUDP doesn't enforce packets being received in-order (being a message-based protocol), while TCP does (being a stream-based protocol).

drawkbox 15y ago
The great thing about UDP with a reliable layer on top is you can choose if you want an ACK back for any 'critical' data. Otherwise you can just ignore order or whether the endpoint receives it or not. It is a broadcast rather than a hard line essentially. For instance let's say you have some physics update and for some reason you needed it networked, with many objects, receiving only 70% of those for many different elements may be just fine (discarding any you receive after that are older maybe for this example)...you may not need reliable acknowledgement that they received for most of them if any. But you definitely need to know when an enemy is killed so you make that a critical message to the server RPC'd to the clients and use a reliable flag which then will expect validation. Same with ordering... use when needed with RUDP or custom layer on UDP for reliability. TCP does all this for you and works great for files/http etc. but doing this for all messages is great overkill in real-time games lower than turn based. And mixing TCP/UDP arguably causes some slowdown to UDP due to TCP queuing. RUDP solves all these issues and is flexible to reliable messages and just firehose broadcast. http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol Designed by none other than Bell Labs... Also SCTP was created to solve RUDP like issues as an official standard (RUDP is a draft) but standards take time: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...
mikeash 15y ago
Enforcing order is hugely important. With TCP, if you lose a packet, all incoming data to the app stops until it's recovered. This is disastrous for an app which can withstand some data being late but needs most of it to show up fast.

drawkbox 15y ago

The great thing about UDP with a reliable layer on top is you can choose if you want an ACK back for any 'critical' data. Otherwise you can just ignore order or whether the endpoint receives it or not. It is a broadcast rather than a hard line essentially. For instance let's say you have some physics update and for some reason you needed it networked, with many objects, receiving only 70% of those for many different elements may be just fine (discarding any you receive after that are older maybe for this example)...you may not need reliable acknowledgement that they received for most of them if any. But you definitely need to know when an enemy is killed so you make that a critical message to the server RPC'd to the clients and use a reliable flag which then will expect validation. Same with ordering... use when needed with RUDP or custom layer on UDP for reliability. TCP does all this for you and works great for files/http etc. but doing this for all messages is great overkill in real-time games lower than turn based. And mixing TCP/UDP arguably causes some slowdown to UDP due to TCP queuing. RUDP solves all these issues and is flexible to reliable messages and just firehose broadcast. http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol Designed by none other than Bell Labs... Also SCTP was created to solve RUDP like issues as an official standard (RUDP is a draft) but standards take time: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol http://en.wikipedia.org/wiki/Stream_Control_Transmission_Pro...

mikeash 15y ago

Enforcing order is hugely important. With TCP, if you lose a packet, all incoming data to the app stops until it's recovered. This is disastrous for an app which can withstand some data being late but needs most of it to show up fast.