Hello Daniweb.

Scenario
For a project we have to write a irc server. For this, we first wanted to investigate what kind of server architecture we should apply. (e.g. multithreading, multiplexing, multiprocessing etc.) We've written simple servers which implement different architectures. The servers basicially receive a message, and then send that message to every user connected to the server.

The next step would be to write a testclient. The client can be given a bunch of parameters to specify things like: "How many clients will the program emulate?", "What's the data size?", "How many times will that data be send?", etc.

The solution so far
I've written this server, but there's a problem I do not know the correct mechanism for to realise it. The way my program is waiting at the moment is as follows:

  • A main thread spawns a number of processes using fork(). (working on linux) These processes will represent clients.
  • Each process executes a function which connects to the server.
  • Once connected, the process spawns 2 threads. Both threads will be given the socket for the server connection. One thread will be used for writing, the other for reading.

The problem:
The problem, is that when you create multiple clients using the application, the first process might already send data before the 50th client is even created. The server will receive this message and send it back to less users than i expected it to, which results in unreliable time measurements.

What I want to achieve, is to have every client "wait" until all other clients are connected to the server.

What I have tried, is to create a signal handler for the main process which contains a counter (static integer). And once connected every child sends a SIGUSR1 signal to it's parent. and start to wait for a signal using sigsuspend(). Once the parents counter hits the number of cients, it sends a SIGUSR1 signal back to all childs.

The problem I encountered with this, is that not all clients receive the signal, because the array which gets updated with the child process ID's get updated slower than the child sending the signal.

Another possibility i've thought of is to use filemapping to create some counter, and a mutex for all processes to use. But I would then have the issue of "how to wait for a value to be a certain number"? I could do something like: "while a number isn't x, sleep for 100ms", but that doesn't seem ideal at all.

Right now i'm thinking of letting the child processes go in sigsuspend() after connecting, and then let the parent wait a pretty long time (say, 10 seconds) after creating it's childs, and then send a signal. But this isn't really safe, and i'm not even sure if it'd work. (the clients won't resume at exactly the same time because the signal doesn't get send to all clients at once, but i think that time diffirence is neglectable)

What is the normal way to approach this type of issue?

Thanks in advance,
Gonbe.

If I understand your problem correctly, I'd just modify the protocol in a following way. Let the connected client, prior to anything else, wait for a "go ahead" from the server. Let the server count the accepted connections. Once the desired count is reached, let the server send that "go ahead" to all of them.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.