I noticed a lot of developers seem to approach network dev as "must do physics on the server" -- which is exactly the wrong thing to do as it takes way too many resources and involves having a complete physics simulation on the server.
The proper way to do it is to just let clients do their own physics calculations, and with one client being the host, send out updates about things periodically, letting other clients correct their state as needed. That's how TNet works.
Yes, IO completion ports are used on windows. Adding DB access -- you'd need to do that yourself on the server side, TNet has no logic for databases.
With TNet you do all your coding in Unity on the client-side. You do actions by sending remote function calls to other clients in the same channel. You can make certain RFCs get saved on the client. You can make object creation/destruction get saved. You can make the entire state of the channel get saved. Working with TNet requires a different way of thinking -- less server, more client. Coincidently, it's very much like Unity's networking in its design.
