This is a text-based server. Text can be relatively efficient for servers, as long as you don't try to make it inefficient with long text values. Using base64 for messages greatly reduces the inefficiency, or even using binary for parts of the messages that could be longer. You start by making an ordinary tcp connection to the server. The server relies upon usernames and passwords. Some out-of-band process is required to create these. INCOMING MESSSAGES (sent by clients) Join server - Provide a username and password. If valid, the server will create a new session for you, and send you message saying connected with the session id. It will mark that session as logged in. All subsequent commands require logged in. If you are in another session, it will end that session. 0:username:password\n (note, usernames and passwords cannot contain :s) Get rooms - Assuming the session is logged in, you can get a list of public rooms. The server will retrieve the list of public rooms from its database, including who is in those rooms and send them to the client. 1:password\n Join room - The server will put you in a valid room, or it will create a room and put you in it. You will start receiving messages from that room, starting with a room_joined message, and then all subsequent messages. 2:room:password\n 2:-1\n - Leave room, this should choose a new room owner or something Send message - You can say "all", "others", or list specific users that should receive the message. 3:0:Message\n - others in room 3:1:Message\n - all in room 3:2:Message\n - others in the room, at once, meaning order is maintained 3:3:Message\n - all in room, order maintained 3:4:u1:u2...:uN:Message\n - others OUTGOING MESSAGES (send by server) Session_started - you know you are logged in, subsequent commands will succeed 0:[client_id]\n rooms - a list of rooms on the server, with counts 1:r1-N,r2-N...\n 2:user_id:room_joined\n - room joined 2:user_id:\n - room left 3:user_id:Message\n - message from sender user_id 4:user_id\n - You are the master client Unity-side. Instantiate message creates a network id, assigning that player as owner --A network id is a simple number + the creator server id, which uniquely identifies it Take ownership reassigns a player as owner. Must use the order_maintained parts above. Update network id sends a packet to specifically serialize parts of an object that have changed. A change flag indicates what parts have changed.