Skip to TL;DR!!!
There's something I've always wondered.
You see, BYOND only uses TCP for their networking capabilities. Me, being in
a game college, I've made networked programs using both TCP and UDP as part of the core curriculum.
Now, the upside to TCP is that you ensure all
packets (discrete blocks of data sent over a network) are received undamaged (or you will know if they are damaged) and in the same order they were sent.
Now, some may say that TCP is far superior to UDP, and that makes UDP completely useless for game development. All of this, based on the fact that UDP doesn't give you the features of TCP.
Well, I have a surprise for you, TCP is essentially made from UDP. UDP is a "streaming" protocol that essentially just throws data over a network in the general direction it wants to go. This is bad, because you aren't sure you're getting the exact data that was sent, and you're not sure each packet is received in the order it was sent.
In reality, TCP does that exact same thing (as UDP), it just uses an algorithm on each side of the
socket (connection between two computers over a network) to ensure that the data is being transmitted properly.
It does several things, some of them advanced, to check the data by using a header in every packet sent.
TCP was created a long time ago and accepted through an
RFC as a "standard" for network transfer. It is quite useful for many applications.
The news is: Like any one-size-fits-all algorithm, it is slower than something made specifically for a given program. It is a really slow protocol for real-time applications, partially because it has to transfer a big amount of extra data in the header and also because of the algorithms it does to maintain correct data transfer.
(Some of said algorithms require sending more/bigger packets. One sizable caveat with networked gaming is how much data you actually transfer. If you transfer less data to achieve the same effect, then your program will automatically be faster. There's one small detail to this, though, that there's sort of a minimum size to a packet that will be sent no matter what -- in which case it is better to pack as much information into one packet as possible.)
Due to the slowness of TCP in real-time, most modern, professional, real-time multiplayer networked games use UDP for networking. They create their own protocol for network transfer that works similar to TCP, but suits their specific application. In this way, they can also optimize their protocol and their game's algorithms to make it run a lot faster than trying to accomplish the same thing with TCP.
One of the problems with network programming, is that, sometimes, you don't get a response from the person on the other end of the socket as soon as you need it. There are ways to change your actual game's algorithm to make this not be a big problem. For example, in a client-server model (which is what BYOND uses), clients send all of their input (mouse, keyboard, etc.) to the server, which then interprets that input and updates their player-character in the server. (The server then has to inform all connected clients of what changed, so everyone connected is up-to-date with what is happening.) Say, for example, a client is pressing the arrow-key to move forward. They sent that arrow-key message to the server, which then moves the player-character and tells all the clients that the player is moving. Now, the next moment, the player that was pressing the arrow key lags a bit, and their data takes time to reach the server. Instead of waiting for the server to tell each client what happens next, the client itself can predict that the player is going to continue moving in whatever direction they were moving, and show that on screen. They can keep doing this until informed otherwise, at which point, they update the position to wherever the player actually is. This looks much smoother and faster to someone playing the game than waiting to receive the next packet before updating. In reality, nothing is faster. It's just a trick to make things seem smoother.
Okay, so the point of that huge essay was my original question: Why doesn't BYOND use UDP? There may be some sort of performance gain if they use it, which will make all games on their system run faster. The only downside (a pretty big one) is that they have to build and maintain their own network protocol. That's not impossible, though. It can be done. Games have done it before, and will continue to do it. The smartest developers know that the way to have fast networking is to use UDP.
TL;DR: UDP is a network protocol that runs faster than TCP, but you have to make and maintain your own protocol for it to be viable. However, it's not impossible to use UDP effectively. So, why doesn't BYOND use UDP?
I'm willing to bet, BYOND used TCP classically, because TCP is far less programmer effort to get going with. But once you start on a route of reliable in-order receipt of data, your data-access model starts to mould itself to rely on that concept. You don't ask the question of "maybe I don't always need to receive X", you just sketch the intended execution out between client and server, relying on that transmission.
But I'll go a little further, and answer the follow on question of "Why doesn't BYOND switch to UDP now?"
BYOND (like many currently TCP applications looking to move over to UDP layered replacements) wouldn't inherently benefit much from suddenly developing a protocol on top of UDP and just casually dropping that in at a point where they presently use TCP, because the application through-out assumes reliable in-order transmission from the network layer. To minimise changes to the application, you'd very quickly find your protocol on top of UDP starts to look a lot like a poor man's TCP, with perhaps a few beneficial characteristic changes.
A proper switch to a protocol on top of UDP means more than a port of the network API, it means a proper whole-scale rethink of when and how BYOND's client and server should attempt to use the unreliable nature of UDP, the out-of-order nature of UDP, and when it requires reliability, or in-order receipt. And that's a pervasive change, even in the best designed systems, when the system is so network I/O bound.
As always, I'm welcome to elaborate and answer questions on this, although it's worth noting, I do not have BYOND source code access, I am simply stating my view-point as a software engineer who tends to deal in networking.