It s almost certainly a reasonable protocol to start with. Remember the cardinal rule of optimization: don t do it. Working with any TCP-based protocol is going to be considerably easier than working with any UDP-based protocol. This is initially much more important to the success of your project than whether it takes 30 milliseconds or 45 milliseconds to send a message between your client and server. Eventually, when you ve gotten to the point where it s clear your project might actually succeed and you really need to make up those 15 (or however many) milliseconds, you can revisit the network layer and consider whether the performance bottleneck (be it latency or some other metric) is due to your choice of protocol. If so, that is the time to spend time evaluating various alternatives. It s only at that point that the effort of selecting the ideal protocol might pay off (since you re that much closer to a completed project) and by then you will have a significantly improved understanding of the problem and should have nailed down your requirements very specifically, two more things which will make the task of selecting the appropriate protocol (be it TCP- or UDP-based) that much easier and more likely to be correct.

To your first question, yes, PB s performance can be perfectly adequate for a real-time game. Several games have been written using PB. For example, MV3D uses Twisted and Python-OGRE to present a shared physical simulation.

To your second question, PB runs upon a stream-oriented transport. It could run on top of "reliable UDP" using something like the PTCP module that comes along with vertex.

However, you should be aware that "reliable UDP" will generally perform much worse than plain old TCP. Routers all along the internet understand TCP and can optimize it by using that understanding. If you implement reliability on top of UDP, by necessity you will need to implement something functionally equivalent to TCP, and then several factors will penalize you:

• your implementation of reliability has to run within your application, not in the operating system kernel.
• your implementation of TCP has to do all the same stuff as TCP, otherwise you will face mysterious bugs in unanticipated network environments.
• routers along the way can t optimize for your custom reliability layer

What can make UDP "faster" in some circumstances is discarding much of the work that TCP does, by being unreliable. If your messaging layer is unreliable, then you have to know that the data it s delivering can be arbitrarily discarded.

Usually, the data that s suitable for transmission over UDP within a game is movement data. When your position changes, you can send a UDP packet and it can be discarded because the game only cares about your most recent position - once an update has been received, all previous positions are irrelevant. So many games send movement data over one (unreliable) UDP channel, then all control messages over a more reliable TCP channel.

But, Jean-Paul s answer about optimization is a good indication of when you might want to consider implementing that optimization.