Arbitrary two-way communication with a UNIX socket

Question

I worked on a complex server-client system in C, and I'm not sure how to implement socket communication.

In a nutshell, a system is a server application that communicates with a database and uses a UNIX socket to communicate with one or more child processes created using fork() . The goal of the children is to launch game servers. The process of starting the game server is as follows:

• The server / "manager" identifies the game server in the database to be created. (Assume the database connection is already sorted.)
• The manager launches a child element ("game controller").
• The game controller installs two pairs of pipes, then forks, replacing its child stdin with a channel, and stdout and stderr with another.
• Then the child controller of the game runs execlp() to run the executable file of the real server.

My experience with sockets is pretty minimal. I used select() in a server application before “multiple” multiple clients, as evidenced by a simple example in the GNU C documentation here .

I now have a new challenge, since the system should be able to do more: the manager should be able to arbitrarily send commands to the children of the game controller (which he will detect by periodically checking the database) and receive answers, but also expect arbitrary commands / errors from them and send responses back.

So, I need some kind of "context" system, where sockets make sense only among themselves. In other words, when a command is sent from the dispatcher to the game controller, each side must know who is asking and knows what the answer is (and therefore which team is the answer).

Because select() is only useful to know when we have incoming data, and the thread must block it, do I need another thread that sends data and receives responses? Will this require each game controller, although technically a “client”, to use a listening socket and also use select() ?

Hope I explained the system and the problem briefly; If necessary, add additional information. Thanks!

Answer 1

Well, I'm still not quite sure that I understand exactly where your problems are, so I’ll just talk about writing a client / server application. If I'm not up to date, just let me know.

• The way the server will know which clients match what the socket is is what the clients tell the server. Essentially, you need to have a login protocol. When the game controller connects to the server, it will send a message saying: "Hi, I register as the foo1 controller on the host xyz, port abc ..." and all that the server needs to know about its clients. The server will store a data structure that maps sockets to client metadata, state, etc. Whenever he receives a new message, he can easily map from the incoming host / port to his metadata. Or your protocol may require that the client send a name registered as a field for each incoming message.

• Request / response processing can be performed in several ways. First, let's look at its server side network part. One way to manage this, as you mentioned, is to use select (or poll or epoll) to multiplex the sockets. In fact, this is usually considered a more difficult way to do things. Another way is to release a thread (or develop a process that is less common these days) for each incoming client. Each spawned thread can read its own assigned socket, responding to messages one at a time, without worrying about other clients other than the one it is dealing with. This simple one-to-one topic for the socket model breaks down if there are many clients, but if it is not, then it is worth considering.

In part 2, only the client really sends a message to the server, and the server responds. What happens when a server wants to start a conversation? How is this done and how does the client handle this? In addition, as you model the communication model at the application level, that is, assuming that we have a read / write part, how do we know what to send? You will probably want to model things in terms of state machines. There are also many more problems with what happens when a client crashes? How about a server crash? Besides, what if you really have your choice from a set, perhaps because you expect many customers? I will try to add even more to this tomorrow.