advice on client - server architecture

Question

I am making a proof of concept-application that maybe one day will be a source of income.
The data-flows dictates that have to be a client - server app, information is shared between clients and should be persisted.

I have experience of writing stand-alone apps, I have modelled the app and have written the client. The communication with the server is only a stub.

So now I have a protocol in form of an (C#) interface with method calls.
Four of the calls is for requesting information and two for pushing data to server.
The data is in classes that I would like to freeze-dry and revive on the other side.

In the future I would like to port the client to other OS'es so I wouldn't like to do something that I have to rewrite the server from cratch, if I can't avoid that.

I would also like to update the data in the client at undetermined intervals. Today I don't know how to do that.
My application is single-threaded, Windows Forms

My assumptions is that:
* I will use TCP/IP in some form below everything. I have to set up the channel, set IP adresses and stuff like that, I have an idea what I have to do.
* The front-end of the server will be multi-threaded to allow for more that one client to talk with the server at the same time. The syncronising will be internal to the server.
* Projected amount of data, maximum : Text 1000 * 1kbyte, 100 000 objects with 4 states. 20 000 updates/day. But that is way in the future.

May three biggest question is
1. Communication protocol . How do I map my method calls, the ones I have in the interface to something that I can transmit on a TCP/IP channel?
2. I need advice on a good pattern to serialize the reading and writing into the "data base", data base doesn't need to be a sql server.
3. Can I allow the server to send updates to the client without making it a multi-threaded app with one thread only listening to the socket?

I will happily update my question if more information is needed.
Thanks in advance.
Gorgen

Answer 1

SOunds like a good candidate fror .Net remoting.

This will abstract away a lot of the low level byte shifting, and allow you to write comms code in domain level language.

Answer 2

From the sounds of it, WCF is right up your alley. Although it can be a little complex at first glance once you start digging into it things are fairly straightforward. This way you let the framework handle asynchronous calls and wiring up the network side of it.

As far as the server sending updates to the client, you'll want to look at a duplexed binding in WCF and on the server side maintaining the list of known (connected) clients. Of course wrap any calls back to the client in try-catch blocks since you never know when a hiccup will occur and the client is suddenly inaccessible.

Answer 3

I just wanted to add some flesh to Agent_9191's answer and record the steps I took for the posterity :

Question 1

• Read Getting started tutorial carefully (no I didn't but I wished I did)

• Changed the example to my fit my own interface

• The default generated proxy changes the interface quite substancially; All collection classes is made to array and all classes that you want to transfer is stripped of all methods, due to the delivery mechanism. To access the domain classes both in server and client follow the advice of this post

• The domain classes that will be used have to be serializable with [DataContract] and [DataMember] from System.Runtime.Serializion.dll

• These WCF samples helped me to understand what's going on too

Question 2

• Made a class that implemented my interface again

• added an static instance in the Service
  private static MyManager myManager = new MyManager();

• simply forwarded all the calls
  public Project[] GetProjects() { return myManager.GetProjects(); }

Question 3

Two-way contract: How to: Create a Duplex Contract

I will have the state in memory and not in a database for now, when I change that I will rethink the approach.

Answer 4

1) Please elaborate on this question a little bit. I don't fully understand what exactly you want explained here.

2) I'm not sure what you mean by this (don't know anything about patterns in the programming sense) but would it not be wiser to read and write asynchronously so that you only access the database when you have something to read/write

3)Yes this is doable but you really should create another thread to update your clients. This is advisable for a few reasons, but mainly you want to compartmentalise your program logic as much as possible to allow you to isolate problems within your software a lot more easily.