> Some game developers, when confronted with a TCP problem, think "I know, I'll add UDP." Now they have two problems.
Games that implement their own protocol over UDP typically have packet modes (frequently a "channel" akin to WebSocket channels): reliable, ordered delivery or neither or either. There is almost always the notion of a connection, where appropriate. This is the correct way to do things, and with Raknet now being free you really have no excuse to do it any other way.
For authentication you could just use the reliable/ordered channel and carry on as though you were using TCP - which somewhat defeats the purpose of this article.
Thanks for sharing by the way, great article (although as an aside, some of those graphs are really hard to read).
I have to admit that I had to squint a bit while reading it myself.
I'm not sure how realistic a threat this is. Most likely crypto just helps obfuscate the game to make cheating/RE a bit harder.
While authentication over UDP is indeed a bit more difficult if implementing it yourself, fortunately there is DTLS which is a very official and well-recognised way to implement authentication over UDP (very briefly - DTLS does make a handshake, and it does have a session, but this session operates in a packet-oriented mode which supports reordering and packet loss).
Sorry to nitpick but UDP seems like the wrong protocol for authentication. TCP is connection oriented. It's a better choice for logging in, refreshing a server list or any transaction where reliability is more important than latency. Most online multiplayer games use both TCP and UDP for this reason.
As for encryption, of course you should always use it when transmitting sensitive data. For a game where the client has no control over the state of the world and all packets are at the discretion of the server (`move here`, `click that`, etc.), encryption might be overkill. The source port value (first 16 bits of a UDP packet) can be used to identify the source of a packet and associate it with a client's server side session. But I'm not saying that encryption is a bad idea (it never is); it just depends on how much you can afford.
[1] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...