views:

156

answers:

5

I am implementing some networking stuff in our project. It has been decided that the communication is very important and we want to do it synchronously. So the client sends something the server acknowledges.

Are there some general best practices for the interaction between the client and the server. For instance if there isn't an answer from the server should the client automatically retry? Should there be a timeout period before it retries? What happens if the acknowledgement fails? At what point do we break the connection and reconnect? Is there some material? I have done searches but nothing is really coming up.

I am looking for best practices in general. I am implementing this in c# (probably with sockets) so if there is anything .Net specific then please let me know too.

A: 

If both the client and the server are written in .NET/C# I would recommend WCF insted of raw sockets as it saves you a from a lot of plumbing code with serialization and deserialization, synchronization of messages etc.

That maybe doesn't really answer your question about best practices though ;-)

Anders Abel
A: 

The first thing to do is to characterize your specific network in terms of speed, probability of lost messages, nominal and peak traffic, bottlenecks, client and server MTBF, ...

Then and only then you decide what you need for your protocol. In many cases you don't need sophisticated error-handling mechanisms and can reliably implement a service with plain UDP.

In few cases, you will need to build something much more robust in order to maintain a consistent global state among several machines connected through a network that you cannot trust.

mouviciel
A: 

The most important thing I found is that messages always should be stateless (read up on REST if this means nothing to you)

For example if your application monitors the number of shipments over a network do not send incremental updates (+x) but always the new total.

Christopher Oezbek
That makes perfect sense. Good advice. Luckily for us our messages are stateless. This is more by coincidence than by design though :)
uriDium
Good for you! I recently had to retrospectively change an application which had toggle-messages for all sort of things, which eventually would always get confused.
Christopher Oezbek
Stateless is a good general guideline, but not *always* required. Some scenarios really demand non-stateless messages - it depends on the situation. However, going stateless first is a great heuristic. And something like a "toggle message" is inherently bad. On the other hand, as I pointed out in my answer, something like "increment" is often exactly what you want, as it will always do the correct thing on the server (vs. "set to 5" if you think the current value is 4)
kyoryu
+4  A: 

First rule of networking - you are sending messages, you are not calling functions.

If you approach networking that way, and don't pretend that you can call functions remotely or have "remote objects", you'll be fine. You never have an actual "thing" on the other side of the network connection - what you have is basically a picture of that thing.

Everything you get from the network is old data. You are never up to date. Because of this, you need to make sure that your messages carry the correct semantics - for instance, you may increment or decrement something by a value, you should not set its value to the current value plus or minus another (as the current value may change by the time your message gets there).

kyoryu
A: 

In a common think about network programming, I think you should learn about :
1. Socket (of course).
2. Fork and Threading.
3. Locking process (use mutex or semaphore or others).

Hope this help..

deddihp
Hi, thanks but not really. All of that stuff is fine. I was just looking for some general guidelines. For example uses of ACKs etc.
uriDium
Instead of learning about threading, I'd learn about non-blocking IO (if working at a socket level, that is).
kyoryu