Best approach to designing multi-client applications

Question

I was wondering how you guys start out if you need to design a multi-client project where multiple clients can interact with a server. In specific how do you go about dealing with different states and message handling, how do you start designing and considering all these cases?

For example a video webchat application where it is possible that you call another client, while that client is already in a call, or is stuck in a modal dialog such that the calling dialog does not come through.

Answer 1

A programmers nature is to have the belief that data loss can be stopped. This is true but it will come at the expense of something else.

This is extremely common when dealing with multiple users accessing the same data and making modifications on it.

• Do you lock the data for editing purposes and decrease the usability of the overall product?
• Perhaps you take the mantra that last in wins in an editing scenario?
• Maybe the approach is to simply isolate each user with their data and merge it at a given point in time; however that will provide an entirely separate set of caveats in and of itself.

Whatever the decision you will inevitably reach a use case where a decision has to be made to either toss the data or throw up your hands. Often times the best approach in this scenario is to throw up your hands and allow the user to make the decision. When you push the decision to the user; you can't go wrong. Do not make this habit however as a user should not constantly be forced to interact and make decisions that the software should be making. Pushing these types of decisions to a settings area can prove beneficial as it allows the user to define their decision ahead of time.

Answer 2

This is a Huge subject.

However, there are some things you can do to make it manageable.

The server has shared state. That means multiple readers and multiple writers. You have many, many choices for handling this.

1. A database. Most databases include locks to prevent concurrent writes.

2. Locking. You can use OS-level locking on the filesystem to allow concurrent writes.

3. Transaction serialization. You can queue update requests into some kind of transaction serializer. Often, the queuing devolves to locking a file, but some message queues don't involve file system locks.

Once you have a way to write shared state, you now need a way to handle multiple, concurrent client connections. You can use processes or threads or some combination of the two.

You often want to have authentication (who a user is). You often want to have authorization (what that user is allowed to do.) There are several ways to handle this. OS's do it. Databases do it. Or you can use an LDAP server to maintain this information.

You may want to have a "session" where a user connects, is authenticated, and remains connected until their session ends. TCP/IP can help you handle this.

One of the great things that's happened in the last few years is the evolution of a standardized architecture for multi-client applications. It's sometimes called The World Wide Web.

Often, it works like this.

1. You have a database. MySQL or something similar. This handles persistence, locking, multiple writers and multiple readers for you.

2. You have a web server. Apache HTTPD or something similar. This handles multiple concurrent client connections for you.

3. You have a web application framework. This can handle authentication, authorization and session management for you, saving you from having to write all that.

4. You write your application as web-based transactions using the web framework and the various servers.