Questions About Server Loops

[Zakkle]

I asked this, recently, on the IRC channel.

Please bare with me.  Understand, I can't think for shit, and I have to start the discussion from scratch, in terms I can understand.  Please state things naturally, as you naturally would, and with the understanding that I have searched the forums and Google for things related to this question.  I just need to ask specifics, in order to get the answer for which I am searching.

I have a problem.  I'm trying to use sfml-network.  I also have short-term memory loss.  I need someone willing to break out the crayons and spell things out for me, Barney style.  I've read manuals, I've passed Networking 101+ classes.  I just need some simple yes-or-no questions to be answered for a vet who can't remember how to tie his own shoes.  Is there a place for me?

I'm trying to use sfml-network to run five threads.  One accepts incoming connections.  One accepts incoming packets from already-connected sockets (clients).  One processes all logic for the server (unrelated to discussion, obviously), another sends all pending outgoing connections. The fifth thread will end all connections that haven't sent a heartbeat within the last x [time], or have been queued for logout.  Also unrelated, there is a sixth, seventh, and eighth thread for connecting to the database and doing everything pending in the database thread.

Anyway, the question is, this:

Is this sufficient for an incoming socket?

if (listener.listen(53000) != sf::Socket::Done)

  ? So, from here, the server inserts the socket into a vertex, ofc, and then loops for incoming packets in the next thread.

Also, is this sufficient for merely looping and accepting incoming packets from already-connected clients?

if (Socket.Receive(Packet) == sf::Socket::Done)

When the server receives a packet, it parses it, but is it sufficient to just loop the thread until the packet received is for an already-connected client?

Can the multiple threads keep looping and checking for the different things, on the server?  That is, incoming clients, client packets for those already connected, timeouts for for already connected?

Or, do I really need to make them all non-blocking and deal with the thousands of loops per second?

[rubenwardy]

Unless you're specifically aiming for an MMO server (which I recommend avoiding) then you don't need to use threads like that. You can receive packets in a non-blocking fasion, and then update any states and such in the same thread. If you want to support massive parallism, then it's worth looking into things like farmer/worker and spatial workers instead of the design, as it'll scale much better.

Avoid over engineering, the simpler solution tends to be cleaner and better. That being said, over-engineering is fun

[Zakkle]

It's an ORPG. I don't see why it should be avoided.

This project is specifically for adding multi-threading.

I'm aware of the design concepts.

I just want some discussion on how to handle dealing with hundreds of users connecting and sending packets. I don't need the listener to tie up the line, and I don't need the receiver to do all the work when another thread can do it without holding up the process.

I'm working with all of the connections being stored in one place, and all the threads using their data to determine where to send packets, and from whom the packets are coming.

What I need to know is, is this sufficient enough, in the long run, to avoid blocking the socket?

[eXpl0it3r]

I already mentioned it on Discord, have you checkout SocketSelector?

As for your NFR, don't try to build something for requirements that you'll never meet. Unless you have really hundreds of people waiting to connect to your application right now, don't try to build for the scenario. Not to forget that synchronizing hundreds of clients isn't trivial at all. You can certainly try, but if you depend on others to explain/solve things for you, then maybe it's not the best way to go.

Even if you want to build for a larger user pool, don't dismiss solutions because you think they won't perform, but actually go, implement and performance test them. You may be surprised how well it works despite your initial dismissal.

I also recommend reading the networking section on the FAQ, it contains a lot of valuable information.