selector.wait() - many Sockets ready

[Sayiain]

In the Reference I find:

bool sf::SocketSelector::wait (Time  timeout = Time::Zero)

This function returns as soon as at least one socket has some data available to be received. To know which sockets are ready, use the isReady function.

In the Tutorial I read(short):

// The listener socket is not ready, test all other sockets (the clients)
for (std::list<sf::TcpSocket*>::iterator it = clients.begin(); it != clients.end(); ++it)
{
   if (selector.isReady(client))
   {
      //Receiving data
   }
}

This example generates complexity N. I would lower it to approx. N/2 by breaking the loop after finding the ready client. But I am afraid that there would be more than one client ready.
My problem:
If you can imagine any example when there is more than one client ready, please explain it.
If there is anything else important to know about why I should check every client after the first found as "Ready", tell me.
Thank you.

I haven't find the answer on google, nor in any present topic.

[Laurent]

If you can imagine any example when there is more than one client ready, please explain it.

Multiple clients sending data between two consecutive calls to selector.wait.

[Sayiain]

1. Can a client become "Ready" after wait() returns true and before another wait() is called?
2. At which point a client becomes "Ready"?
3. Is selector.isReady(client) equal to client.receive(packet) or getting "Ready" takes place before receiving?
4. Would:

client.receive(packet);

be equal to:

client.receive(packet);
packet.clear();
client.receive(packet);

[Laurent]

Your questions are really strange. In fact you have no idea what all this stuff is about, have you?

The logic here is dead simple:
1. "I'm waiting until someone has something to give to me"
2. "everyone who have something for me, give it now"
3. go back to 1.

What exactly don't you understand, that makes you ask so many questions?

[Sayiain]

I want to optimalise the programme Therefore I want to minimalise iterations. If I know that the following clients aren't ready I can break the loop.
Here comes my first question:
Can a client become "Ready" after wait() returns true and before another wait() is called?
I cast wait(). Something is sent(). wait() returns true and processing begins.
You noticed only a situation when there is something sent() before wait(). I assume that in the beggining there is only one "Ready" client. Am I correct?
While the precessing continues something can be sent(). More than one thing. This can be sent() to any client.
I assume that sent() data are recived not only during wait().
Lets say I have 100 clients. I got a packet to client10. But during the processing I got 2 more messages to client40 and client80. I haven't pass then in the iterating for loop. Would they be "Ready" when the iteration comes to them?
Here comes my 2nd question:
At which point a client becomes "Ready"?
At the point of incomming data or at the point of catching the data by the wait() function?
Is there some stack that is cleared by the wait() function? Or the wait() function only informs when the stack is filled? After wait() returns true, do receive() functions pop the messages from the stack?
And that were my 3rd and 4th questions.

As I mentioned before I want to optimalize. I want do build request counter/statistics for each client.
If I know that there is no more packets to process and can call break; I would sort the clients by their sending frequence descending and avoid many many if(selector.isReady(client)).
Is there any way to know how many(not which) clients are "Ready" other than iterating each?

Anyone who can help me understand - Thank you.

[Jesper Juhl]

When you call wait() you are doing a very simple thing; your are asking "please tell me as soon as one or more sockets are ready or the timeout expires". If one or more sockets already have data waiting (are ready) then wait() returns true at once. If no sockets have data ready wait() blocks until at least one becomes ready and then it returns true. If no sockets are ready and none become ready before the timeout expires, then wait() returns false.
After wait() returns true you need to find out which sockets were the ones that were ready so you can go and read their data. And yes, multiple sockets can be ready and you don't know which ones until you have tested them all. And also yes, multiple sockets can become ready between two calls to wait() if the kernel receives data on them between the two wait() calls - in this case the second call to wait() will return immediately since sockets are already ready.

Regarding optimization: don't worry about it. Make simple robust code that is easy to reason about and is easy to prove is correct. Then later, if you run into performance issues, use a profiler to see what is causing the trouble and only then optimize those specific areas. And trust me, looping over 100 sockets to check them for readyness is not going to be a performance hotspot.

[Laurent]

I want to optimalise the programme

You're not going to optimize much in this direction. Before optimizing, start by identifying what needs to be optimized. Right now you're just wasting your time with questions you shouldn't ask.

[Sayiain]

And also yes, multiple sockets can become ready between two calls to wait() if the kernel receives data on them between the two wait() calls

This is very helpful information. Thank you very much Jesper Juhl.

Now I am only wondering if creating a thread for each client doesn't fasten the performance...
But I will search for it in other topics.

[Jesper Juhl]

No, no, no. Don't complicate things with threads. Especially not when you are fairly inexperienced (which is my impression).
Threads will only make things harder for you - much harder. And you don't need them at all for something this trivial and non-critical to performance (at least not until you scale far, far beyond 100 clients). Get things working correctly first. Then profile if performance is bad and maybe then employ threads if (and only if) the profiler indicates that they might be a good tool for the job - don't make your life harder than it has to be before you really need to - non-blocking sockets and a single thread will serve you well for most things.
Please take a look at this thread: http://en.sfml-dev.org/forums/index.php?topic=15430.0 and also the two other threads that are linked in there.

[select_this]

To add to Jesper's point, a thread-per-client model can easily end in disaster if not handled properly, especially if the clients share state.