Client/Server application: networking issues design

Hi,

I'm developing a multiplayer game. I'm writing both client and server application.
Client applications need to perform these two tasks:

• Receive messages from Server
• Send requests and read responses from the server right after

The first one is to be able to read events notified from the server. While the second one is a little more complex: it requires a Send() call, but the server in the other side will answer this request at the moment it receives it. And client, depending on the answer from the server, will send a request again and the loop can continue. So, basically, in the client I need a code like the following one:

Code:

---

    //Code to send requests and read responses from the server
    ServerSocket.Send(request);
    response = ServerSocket.Receive();
    if(response is type X)
    {
          ServerSocket.Send(newrequest);
          response = ServerSocket.Receive();
    }

---

but I also need a code, running in a parallel thread, like this:

Code:

---

    //Code to read events from the server
    while(Application is running)
    {
          event = ServerSocket.Receive();
          //Act depending on the event
    }

---

Is possible to do it using just one socket?. If it's not, what would be the best approach?

Regards.

I want to share with you all what I found so far, may be it's useful for other people too. The main conclusion is to never spawn a thread for each client connection in the server. It consumes cpu time just switching between threads. So, any application that has to be scalable needs to avoid seriously this design.
To create high-performance servers we can count on IO Completion Ports. .Net Framework Socket class exposes methods to work asynchronously and implements IO Completion Ports. But since .Net Framework is a wrapper for Windows API, there's a lot of marshaling and interop operations that have a hit in the performance, but .Net Framework 3.5 has improved them.
Despites of all that I said, I found that to develop trully high-performance servers we need to go back to the sources: C/C++.
What will I do?. I'll stick to .Net Framework async methods for now to launch my application to the market as soon as I can. If I see that it grows on popularity and it has a future, I'll start to develop the same server in c++.
I hope that someone may find these comments useful.

Best regards.

Quote:

---

Originally Posted by mariano_donati

If it's not, what would be the best approach?

---

In my opinion, do simple thing for your task #2 ("Send requests and read responses from the server right after") and don't fall into ports and all.

Use/Install Web server on your server (IIS or Apache) request data using HTTP GET or POST async something like WebRequest.BeginGetResponse

That way you will request something from the server using HTTP and when you get response the callback function will process the response.

the right way of doing it may be a WCF service hosted either in your server's IIS or hosted in your Server's WinForm app, and use that service.


About .NET and performance, I feel using .NET is for easier and faster for development, and for cheaper cost of development, and if you start with C/C++ you will surely have to handle many things like memory management, threading, and there are more chances of Memory leaks... in .NET it is much easier to do performance and/or memory profiling. and your applications will be easily upgraded to next versions of .NET framework which may be better of get most of the OS and Hardware.

Sorry for long reply but got scared that you are thinking of switching to C/C++ as .NET earns me my bread & butter :)


Regards,
Vishalgiri Goswami

I haven't thought about a WCF. But I think that using it will take more bandwith since it has to send more data within each packet. My messages haven't more than 20 bytes each.
I did think about doing it with http requests, but the same thing occurs. I would send and receive information that I don't need to, the protocol does.
You said you're sorry for your long reply, but I appreciate it very much.

Thanks.