73 lines
5.0 KiB
Plaintext
73 lines
5.0 KiB
Plaintext
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 colons :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
|
|
|
|
4:group:Message\n - message a specific group
|
|
5:group:c1:c2:c3\n - specify a named group of clients (used with 4)
|
|
|
|
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 - New master client
|
|
|
|
|
|
|
|
Unity-side.
|
|
|
|
The server is relatively stupid, by design, as it's just a relay (for now). The Unity side is pretty complex.
|
|
|
|
NetworkManager - Deals with instantiating NetworkPlayers, and dealing with join, left, new master client events. Also manages the list of NetworkObjects. It maintains a list of prefabs that can be instantiated, as well as the prefab to use for players.
|
|
|
|
NetworkPlayer - One of these will be instantiated for each player that joins the "room". Most application communication happens by calling methods on this object. Voice comms are also handled within this object. Only one NetworkPlayer "isLocal". The others are remote. The local network player is the one that can modify it's "owned" network objects. It also has a special networkobject representing itself (setup within the prefab, not part of the networkmanager list). This is where most of the user behavior is going to go (e.g. an avatar).
|
|
|
|
NetworkObject - Something that can be owned by a network player, who is responsible for updating it. Only the owner network player can/should modify a network object, whether locally or in response to a received message from the local version. NetworkObjects are delineated by an session-unique id, which consists of the creator's userid + "-" + an increasing number designated by the creator. Only local NetworkPlayers should send instantiate message, which contain this id. This class should be extended to sync and send messages. Scenes are basically built from NetworkObjects. Scene's can also start with network objects. Those are known by all, and start with "-1-increasing". That should happen the same on all clients, and is done locally at the start of the networkmanager. An example of a NetworkObject is SyncTransform, which is a simple one that keeps an object's position and orientation synchronized.
|
|
|
|
Ownership of objects changes regularly. Any local networkplayer can send a message to take ownership of a networkid. That client immediately assumes ownership. The message is sent to the network, and will be ordered with any other ownership messages. So, if two clients try to get ownership at the same time, both will assume ownership, but one will happen after the other. This means that the one who was first will quickly lose ownership.
|
|
|
|
An interesting problem is what to do when new clients join. This is partially left up to the developer. Any objects that are instantiated (or scene objects that are deleted) will be automatically handled. (todo-include an instantiation packet).
|
|
|
|
Clients can manage network traffic using messaging groups. This is especially useful for audio, where you can maintain a list of people close enough to you to hear audio
|
|
|
|
Todo:
|
|
|
|
Scene objects that are destroyed need to be buffered to new clients.
|
|
Instantiation byte[] (full sync, basically).
|
|
Need to determine what happens when you specifically leave a room (session).
|
|
|
|
|
|
|