Sockets and threads! How to scale well :P
-
I have a C++ WinSock based client-server system which has the following design: Client: a. For each request, client connects to the server b. Sends the input data c. Waits for response (During this server does the processing and sends output) d. Presents the results to the client e. Socket connection is broken Server: a. Server waits in listen() loop b. For each request, it spawns a thread c. De-serializes input data d. Does business logic and database operations e. Transfers output to the client Basically it is a synchronous multi-threaded socket based client-server solution with a simple design and adequate scalability. We have used it for years for upto 10 concurrent users and constant request-response cycles. Note that the request and response may consist of fairly large (e.g. 10 to 100 MB) files also. Now we are re-designing the software with C#... I would like to know the optimal way to design the system, so that it is highly scalable. Please give your suggestions. Thanks a lot ! :)
-
I have a C++ WinSock based client-server system which has the following design: Client: a. For each request, client connects to the server b. Sends the input data c. Waits for response (During this server does the processing and sends output) d. Presents the results to the client e. Socket connection is broken Server: a. Server waits in listen() loop b. For each request, it spawns a thread c. De-serializes input data d. Does business logic and database operations e. Transfers output to the client Basically it is a synchronous multi-threaded socket based client-server solution with a simple design and adequate scalability. We have used it for years for upto 10 concurrent users and constant request-response cycles. Note that the request and response may consist of fairly large (e.g. 10 to 100 MB) files also. Now we are re-designing the software with C#... I would like to know the optimal way to design the system, so that it is highly scalable. Please give your suggestions. Thanks a lot ! :)
The only suggestion I have is to use a ThreadPool on the server instead of spawning a thread directly. Threads tend to have high overhead for launching. -- Joel Lucsy
-
I have a C++ WinSock based client-server system which has the following design: Client: a. For each request, client connects to the server b. Sends the input data c. Waits for response (During this server does the processing and sends output) d. Presents the results to the client e. Socket connection is broken Server: a. Server waits in listen() loop b. For each request, it spawns a thread c. De-serializes input data d. Does business logic and database operations e. Transfers output to the client Basically it is a synchronous multi-threaded socket based client-server solution with a simple design and adequate scalability. We have used it for years for upto 10 concurrent users and constant request-response cycles. Note that the request and response may consist of fairly large (e.g. 10 to 100 MB) files also. Now we are re-designing the software with C#... I would like to know the optimal way to design the system, so that it is highly scalable. Please give your suggestions. Thanks a lot ! :)
I recommend going with either Web Services or .NET Remoting over HTTP hosted by IIS (which is exposed as a Web Service, so it's still one-way request/response). Scalability is handled by IIS leaving you with the higher-level functionality. I also recommend implementing the WSE (http://msdn.microsoft.com/webservices/building/wse[^]) and using DIME to transfer files. It's a very simple API and does not require that the documents are serialized to a
byte[]array like when you transfer it over the wire using Web Services or .NET Remoting. It's a binary wire format, and an industry standard to boot. I recommend this because writing a socket client/server system and doing the serialization yourself is fine, but there's functionality for that already in the .NET BCL through Web Services and .NET Remoting. Besides, Web Services are also an industry standard and open up new client possiblities that may otherwise be more difficult with a standard socket server (have to take endianess and packing into account). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] -
I recommend going with either Web Services or .NET Remoting over HTTP hosted by IIS (which is exposed as a Web Service, so it's still one-way request/response). Scalability is handled by IIS leaving you with the higher-level functionality. I also recommend implementing the WSE (http://msdn.microsoft.com/webservices/building/wse[^]) and using DIME to transfer files. It's a very simple API and does not require that the documents are serialized to a
byte[]array like when you transfer it over the wire using Web Services or .NET Remoting. It's a binary wire format, and an industry standard to boot. I recommend this because writing a socket client/server system and doing the serialization yourself is fine, but there's functionality for that already in the .NET BCL through Web Services and .NET Remoting. Besides, Web Services are also an industry standard and open up new client possiblities that may otherwise be more difficult with a standard socket server (have to take endianess and packing into account). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]Like Heath said, use a web service but we found that DIME wasn't very good at handling large documents since it could not stream. possibly u can use a webservice which returns a http url of the file to be transfered. The client receives the url and uses http protocol to download the file. U can google for software which will help u to download using http protocol ex: sharpdownload project--sourceforge.net ) cool man
-
Like Heath said, use a web service but we found that DIME wasn't very good at handling large documents since it could not stream. possibly u can use a webservice which returns a http url of the file to be transfered. The client receives the url and uses http protocol to download the file. U can google for software which will help u to download using http protocol ex: sharpdownload project--sourceforge.net ) cool man
You can chunk large files using DIME - it's part of the specs. Why does he need extra software to download files via HTTP? The .NET Framework BCL already has this. Use
WebClient.DownloadFilefor the simple way, or useHttpWebRequestandHttpWebResponsefor a little more control and feedback. There's no need for an extra library. It's simply a waste. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] -
You can chunk large files using DIME - it's part of the specs. Why does he need extra software to download files via HTTP? The .NET Framework BCL already has this. Use
WebClient.DownloadFilefor the simple way, or useHttpWebRequestandHttpWebResponsefor a little more control and feedback. There's no need for an extra library. It's simply a waste. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]We found that WebClient.DownloadFile or HttpWebRequest and HttpWebResponse has problems when the user is using proxy. we tried using proxy class to supply relevent information that also did not work. Further the download seemed faster with the extra library since it downloaded parts of the file (using threads) and joined them later. we dint have any problems with the proxy also. Does the BCL classes also implement the same? cool man
-
We found that WebClient.DownloadFile or HttpWebRequest and HttpWebResponse has problems when the user is using proxy. we tried using proxy class to supply relevent information that also did not work. Further the download seemed faster with the extra library since it downloaded parts of the file (using threads) and joined them later. we dint have any problems with the proxy also. Does the BCL classes also implement the same? cool man
I don't remember off the top of my head, but I believe that was fixed in .NET 1.0 SP2. I know it's not in the list of fixes for .NET 1.0 SP3 & .NET 1.1 SP1 (I got on this team at the time of their release). This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]