Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
The example you have given is related to poor user interface design. If you have to be able to handle multiple simultaneous events, handling events individually using modal dialogs will not work - events will get blocked. – Michael Shaw Jan 7 '11 at 15:11
The example might be or might not be good, I'm still wondering what the best process is to come up with a good architecture for both the UI and backend of such applications to handle events properly. – TomHastjarjanto Jan 7 '11 at 15:22

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.