Multi Thread Socket Server and its Clients talking to each other

Question

I have a question that is killing me and I would like to share with you, maybe someone has the answer or a way forward to address this doubt.

I have good experience with Web/Desktop development, API/REST and Socket connections. But all these connections even in a multi thread server (independent of the programming language) I always worked with the client connecting to the server, ordering or sending something, the server responding and if it is no longer necessary is terminated the connection. Turns out I’ve been taking a look at online games (MMO RPG) and there was my question, how a client connected to the server can see the other client, interact, etc...

I imagine keeping a list of all connected clients on the server each with their identifier, so far so good, but how to explain that I can see each connected doing something different? You mean every second so to speak I as a client get from the server the list of active customers and all the status of everyone at that moment? In my head it seems a little heavy if thinking of many users.

So much for my doubt, as I as a client connected to the server I see the other clients and interact with them?

Imagine you’re playing an online game and suddenly a new player comes along and walks, runs, attacks, jumps, rolls all this you see, then another comes along, and another, is that I get a bundle of data telling me about each connected user and what they are doing or am thinking more about the problem and the thing is simpler?

I thank you in advance for each one’s answers and time :)

Answer 1

Good, you should think about the level of communication protocol and what data you really need to display on the screen and when you will receive data and this varies from the type of game.

For example, in a LOL game you do not need to circulate the names of the players over the net during the whole match. Only at the beginning, at the end, are they discarded from the customer’s memory after the game.

In a Tibia of life, you need to circulate that data because there’s not a stage where you can upload that data, it’s going to be displayed during the drive, so the point is probably to focus on the communication protocol, compress the data during the transmission, send only when changing map or interact, ie, analyzes each need for sending data. Not to mention, that separating players by server/region is a common practice because of latency.

Generally speaking, the first step is to analyze what can be placed on the client and what should come from the server.

1- Never, but never, make a customer communicate directly with another without the user knowing and agreeing to it. This is a simple matter of design for the security part, if you design like this, a customer will know the network address of another and 'listening' the connection can have access to the other user’s machine. Another latent problem with this type of design is that latency between different players harms more than one player, because the server has no way to manage direct connections that do not pass through it and would end up expecting too much at some point, including, increasing the complexity of the code to control these things.

2 - Separate the visual information from the messages that make up the game’s communication protocol. One thing is what you see on the screen, another is what circulates on the network between the server and the client, most of the time is why clients are big to download. An example, the name of a monster does not need to circulate on the network, just the number (ID) of the monster that is transformed locally in the image and text on the screen.

3 - All content that can be displayed in a standard way between clients of a session must be placed in the customer’s download for installation. Only control data (object identifiers) should circulate over the network. Basically the flow between the click of a user and an action is send click to the server, server processes, returns customer response. This flow should obviously be only in the sense that animations and positioning perform, never the execution data itself.

4 - Almost last but not least, the server maintains the real status of all objects, maps and interactions, performs the processing and determines the results, whereas the client is only a graphical window that renders and displays the result of the actions, whatever the type of game.

5 - Design the protocol for different types of messages, like some kind of message can be dropped if it gets lost on the network? If yes, UPD, otherwise TCP.

An example of this is the moment you have lag and the screen when it comes back already appears in a totally new (probably dead) position:D

Well, there’s no magic recipe and programming protocols and games is not so trivial.

Edit: Some people have been 'studying' the LOL protocol, you can find these examples on google (eg a link in English :https://nelsonslog.wordpress.com/2014/08/07/league-of-legends-game-protocol/)

Edit 2: An interesting link with the numbers of the guys and a bit of the infra of them (also English: http://highscalability.com/blog/2014/10/13/how-league-of-legends-scaled-chat-to-70-million-players-it-t.html)