Ok so I've been trying my hand at writing various protocols in C#. The problem I'm facing right now is that everytime I do it I never seem to get it quite "right". Either I end up overcomplicating the design, the implementation, or both. My experiences so far can be boiled down to: - Threaded approach on both server and client using blocked send and receive calls on raw sockets over a NetworkStream is easy. - Threaded server and nonthreaded client approach using asynchronous send and receive calls with raw sockets is hard. Really hard. Now, for a realtime RPG game, is it safe to assume that all my clients can handle a couple of IO threads running continiously in the background? And even if it is, more or less, is it still safe to assume that I could make a relatively good protocol based on it? Whenever I use a synchronous approach to my protocols I seem to never quite get the implementation right - too much code being stuck in the same place and too much networking code ending up dealing directly with user input and whatnot. Any feedback?

As a minor grammatical nitpick, the protocol is not threaded. The network stacks is threaded, the application is threaded, but the network protocol is not threaded. Threading a protocol means something rather different, if it means anything at all.

Yes, it's safe to assume your client can handle a few threads running in the background, but if they're running continuously, with no blocking or pausing, it will mean that any other applications will have difficulty running at the same time, which may be fine or not.

As to seeing that there's too much networking code dealing with input, that's a design issue. I advise you to think like an object-oriented programmer when it comes to networking. If one section of the code doesn't need to know about another section, make sure it doesn't. Your network code's lowest layer (and it should probably have a few layers) shouldn't even know it's for a game, and maybe shouldn't even know whether it's the server or the client.

Quote:

is it safe to assume that all my clients can handle a couple of IO threads running continiously in the background?

Clients, yes (if the threads are mostly waiting on blocking I/O).

Servers, no (if it's a couple of threads per client, you'll start losing steam pretty quickly as clients connect).

Thanks guys! :)

I decided to just go with the Ultima Online protocol, at least for the time being, and use the RunUO source for the purpose. I'm basically creating a stripped down version of it to avoid all the Ultima Online specific gameplay bloat (tons of scripts comes to mind), and to get a much better overview of how it works. I think I'm going to end up with asynchronous networking on the client, because looking at the RunUO source has given me a few good ideas about how to properly receive data asynchronously (stack the data in a List<> of bytes and set a timeout on the receive callback), and then implement some sort of outside layer on top for actually handling the received data.

rating++