Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are there any common patterns or general guidance I can learn from for how to design a client/server system where the both the client and server must maintain some kind per-client session state?

I've found any number of libraries that can help with some of the plumbing, but it's the overall design I'm wondering about.

Open issues in my mind:

  • How to structure the client/server communication so that bidirectional synchronous and asynchronous requests are possible?
  • The server side needs to spawn a couple of per-connected-client session-long helper process. How to manage that?
  • How to manage the mapping from a given client (and any of it's requests) to server state and helper process instances in the face of multiple clients and intermittent network connectivity.
  • Most communication can be simple blocking request/reply, but some will be long running processing tasks that the client will want to keep tabs on.

To the extent that it matters, the platform is Linux/C/C++. Not web based. Just an existing thick-client software app being modified to talk to backend servers for some tasks.

share|improve this question
add comment

closed as too broad by Simon, Bart van Ingen Schenau, MichaelT, gnat, Kilian Foth Dec 9 '13 at 12:21

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers

How to structure the client/server communication so that bidirectional synchronous and asynchronous requests are possible?

If you are communicating through a web browser, you'll have to keep in mind the user experience. Long running requests should be asynchronous with a some feedback such as a dialog showing progress. For bidirectional communication you'll want use AJAX or look into comet for server push

The server side needs to spawn a couple of per-connected-client session-long helper process. How to manage that?

On the server side you can have any number of helper threads performing tasks in the background. Your framework should attach the HTTP request to a session, you'll be able to pool helper processes based on that session

How to manage the mapping from a given client (and any of it's requests) to server state and helper process instances in the face of multiple clients and intermittent network connectivity.

An HTTP session will maintain your session attributes. Generally frameworks allow for a session timeout in minutes, so even if your are intermittently disconnected the session attributes will remain intact

Most communication can be simple blocking request/reply, but some will be long running processing tasks that the client will want to keep tabs on.

You'll want to consider some progress information for this, probably updated with AJAX. Progress bars coupled with textual (x out of y completed) with an estimated time to completion are a great way to help update the user and keep them patient

share|improve this answer
    
Thank for the detailed answer. I should have clarified that this is not web based. –  nonot1 Apr 25 '13 at 16:04
add comment

Since this is not a web app, and since I do not know the constraints at the server side, here are some thoughts:

  • How to structure the client/server communication so that bidirectional synchronous and asynchronous requests are possible?
    I would advise making the client and server less chatty, using a coarse-grained API. I'm not sure why a bidirectional channel is required. If its for showing status updates, you could use one of few approaches
    a) Implement a "socket listener" (or some other similar callback mechanism) on the client and have the server periodically connect to this socket to provide updates. This helps free up connections on the server. It is most easily used when the client and server are on the same network.
    b) If the client and server are not on the same network you can have the client periodically poll the server for status updates. On the server side you can use Node.js if you are expecting a huge number of clients to poll.

  • The server side needs to spawn a couple of per-connected-client session-long helper process. How to manage that?
    Having one process per client is not scalable. Instead, its better to have a certain number of "worker processes" on the server which pick up requests from a queue and keep updating the queue, and finally save results back into the queue. In the interim, the client could keep polling for status updates. The pattern would be
    1)Client makes request to server (I recommend using a RESTful API if possible. Else, you can roll your own TCP based protocol). At the server side, the request is added to a queue.
    2)Background worker processes pick up requests from the queue. They process the requests and update the queue with status updates. Finally, results of the request are saved back into the queue.
    3)As mentioned above, either the server can use a callback to inform the calendar, or the client can keep polling the server repeatedly.

  • How to manage the mapping from a given client (and any of it's requests) to server state and helper process instances in the face of multiple clients and intermittent network connectivity.
    The queue may help in this

HTH.

share|improve this answer
add comment

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