I did something similar to what you describe by writing a custom Python server to communicate with a Unity client.<p>Most highly interactive games can't just use TCP, because it has too much overhead and you want different reliability for different kinds of game-data. For instance, if you're sending a constant stream of position updates, you don't need them all to be reliable. E.g. just send the last N frames of updates in each unreliable datagram. That way if one is missed, you can just interpolate / extrapolate. Triggering particle effects or other non-critical eye-candy can also be unreliable.<p>Check out RakNet. It's a really solid C++ networking library optimized for games and similar soft-realtime use cases. Internally, this is what Unity's built-in networking is implemented with. Since I couldn't access Unity's RakNet directly, I wrapped the DLL for access from my own client-side
Unity code. I used custom Python on the back-end.<p>Another option to consider is SmartFox Server. It does things like lobbies, IP block ranges, and sessions management.<p>Chances are you'll end up re-implementing a lot of functionality that they've written already. I was okay with that, because I wanted to learn how.<p>Hope this helps.<p>You should decouple your network polling from the game update loop to avoid headaches later. I.e. don't do it in Update. Also, Update is frame-rate / display-dependent, whereas FixedUpdate is not.