I played a bit with WebSockets and started to implement a tiny chat. Last time I did something like this was when there was no such thing as threads and computers had single core. I started to think how to implement it with todays programming patterns but I didn’t come to any final conclusion.
How you implement chat’s main functionality in today’s technics in higher level?
I now have context Server, Socket and User. User has states Undefined, Connected, InChat, ToBeDisconnected, Disconnected, My main problem is the user maintenance:
- If user hasn’t said “hello” in 5 seconds after connection was opened -> disconnect
- User is not replied to “ping” with “pong” at all or at least 2 minutes -> disconnect
- User has been connected over 12 hours -> disconnect
- User haven’t been assigned profile (nickname and/or other details) after 5 minutes of connect -> disconnect
- Some other program specific flag that kicks out user is triggered -> disconnect
My current implementation is like how it was done in olden days. ie. I have
while(serverRunning)
{
foreach(socket in allSockets)
{
user = allUsers.findUserBySocket(socket);
doMaintenance(user);
}
}
Now this runs far too many times and locks and blocks allUsers and allSockets way too much.
How this is implemented today? Like this for example?
- Socket connects
- Add to allSockets
- Add to allUsers
- Start per-user thread that runs every x seconds and runs user.doMaintenance()?
- Or there’s per-user queue that gets injected with actions like doPongCheckAction, doProfileTimeoutCheckAction, etc every x seconds (also needs per-user thread which constantly empties user’s queue)?
- Or there’s Maintenance thread that runs every x second after last run and iterates through allUsers (a bit like current implementation)?
- Or there’s thread that injects actions to all users queues when there’s been too long when same kind of action were ran and other thread that iterates through all users and empties user’s queue?
- Or something else or which is not even based on queues? 🙂
10
Check out architectural patterns like PubSub or Enterprise Service Bus. Chat rooms can easily be modeled along those lines. A client would connect to the broker and register itself, subscribing to published updates. Also, consider using an established protocol to manage these connections, subscriptions and registrations, something like PubSubHubbub or XMPP are established enough to have thought of issues and edge-cases you haven’t yet, but open enough to let you write your own server, using them as a medium only.
To remain scalable, I would avoid any architecture that is dependent on the number of connections. Spinning up a thread for each user doesn’t scale once the user count goes up and the threads start getting in each-other’s way.
I would do it with one or more timers per user that fire off an event. For example, you could set a pingMissed(user) function to be called every two minutes, which disconnects the user. Every time you receive a ping response from that user, you reset the timer for another two minutes. Timers are supported by the operating system, and use very few resources while waiting.
One way to structure your main loop, very similar to what you have, is to use an event driven architecture:
while(serverRunning)
{
wait(for something interesting on any of your sockets)
{
user = allUsers.findUserBySocket(socket);
doMaintenance(user);
}
}
The wait() operation could be something like select, epoll, kqueue, or some other kernel-provided function depending on your target OS. Essentially you give the kernel the complete list of sockets which you are interested in, then it (efficiently) waits until something interesting happens on any of those sockets. When the wait operation returns, check to see which socket had the interesting event (data received, socket closed, etc) and act accordingly.
To handle periodic events, you can keep a list in your code of the next events to be fired. When you call select or whatever, you can work out what time the next event should fire, and pass a corresponding timeout value to the waiting function.