Difference between Thread pool and asynchronous tcp server

Question

Hello I am doing some literature study on a new project that I will be starting soon. I want to make a server application capable of handling a maximum of 4 clients. I want to be able to read and write to a client at the same time (don't know if this is really possible). I read that using a multi threaded application is better but I don't know if for example an asynchronous server is also multi threaded (I can't see any threads being created). So my question is: What is the exact difference between a thread pool server and an asynchronous server? The problem i a lot of questions araise while reading that I can't awnser myself. Thanks in advance and with best regards.

Sam Hobbs · Answer

Since Hemant's reply is marked as the answer I am confused. Everything that you are saying seems to contradict what that reply says. I agree that your application is simple enough that you do not need complicated thread pool management and such. If you use asynchronous I/O then you might not need a separate thread for each client. I assume that your program will have a UI so you need at least one additional thread for communicating with the robot but there won't be a performance problem if there are a few more threads dedicated to whatever tasks that are needed. You might need a thread dedicated to video recognition and another to control the movements and another to process commands. I think you are saying that there is one client sending video for three cameras. So you might need a separate thread for each camera. So you would have a controlling thread that receives camera images that puts the images in a queue or in each of three queues for each camera and then the thread for each camera obtains the images. Actually you probably do not need a queue unless the threads get overworked. You will need to synchronize the threads using events (AutoResetEvent) or a Mutex; there might be other options. In C# (it is my understanding that) each object has a lock that can be used for cross-thread synchronization. You can investigate the possibility of making the server a service; a Windows Service. In Windows device drivers are services but services can be used for other things too. Services do not have a UI; they work in the background so most users are not really aware of them until something goes wrong. The service will need a way to communicate with a program that has a UI and will learn about that when you learn about services in general. For now it would be most practical to start with everything in one application. You could and probably should make the I/O part a Class Library at least eventually. Keep in mind that the I/O part should eventually work without a UI; that it will only communicate with the UI even for errors except it is typical for a service to write error data to an event log. It sounds like fun. I hope you enjoy it.

Sam Hobbs · Answer

I should have been able to figure out that the diagram showed both physical and virtual connections. I wish I could spend more time on this. I would if I could. I suppose that one answer to many of your questions is that this is a learning experience and it won't be a big problem if you try something and then learn a better way to do things. Probably you have gotten to the point where it is better to create new threads with specific questions. I think there is too much in this thread to attempt to deal with in a single thread.

JR · Answer

Hello Sam Sorry for the confusion I mixed physical and virtual connections in my DIY *.ppt flowchart. The physical connections are: 1. The Host PC that runs the server is connected to a WiFi router using an Ethernet cable. 2. The Client 1 application runs on a NT-A3500 PC that has a built in WiFi connection. 3. The Client 2 application runs on a Netduino board (with an Ethernet connection) is connected to the NT-A3500 PC using an Ethernet cable. The connections between the server and client 1 and client 2 are supposed to be virtual connections: Client 1 to Server 1. With a fixed interval (1000 ms) the GPS NMEA data (string) should be send from the client to the server. 2. I want to make a class that takes a picture in a fixed order from each camera and the image (JPEG with a small resolution)) is send to the server (I assume that this send operation to the server blocks all other send operations (like GPS ect... ?). If yes can and should I run this using a separate client? 3. With a fixed interval (2000 ms) diagnostic data (string) should be send from the client to the server. Server to Client 1 1. Manual commands can be send from the server to the client using a textbox and send button. So the interval is dynamic. Client 2 to Server 1. With a fixed interval (500 ms) diagnostic data (motor speed drawn current) (string) should be send from the client to the server. Server to Client 2 1. With a dynamic interval (when available) motor directions coming from the GamePad should be send to the Client 2 I don't know how to accomplish this all but I am working in different phases. At the moment I am busy programming the server end of the application (including packet handling gamepad commands ect..). The clients (at the moment) are two putty programs running on the same PC (localhost). I don't know if I really need three threads or a queue? I am just doing research on what would be the best way to do this. BTW: I will study the queue class later this day. Cheers

Sam Hobbs · Answer

That is a nice looking flowchart. I don't know if client 1 needs 3 threads. Do you know what a queue is? Are you familiar with first-in-first-out (FIFO) stacks? Look at the .Net Queue class. Would it be sufficient to use a queue and one thread? Why do you think you need 3 threads? You might be correct that you need three threads but I don't understand why. I suggest that you design a way to do the development in phases. Such as just receive camera images. Or whatever is possible and practical. In your flowchart you show communication between the server and the clients and you show the WiFi. Does the communication go through the WiFi? If so then the flowchart seems confusing.

JR · Answer

Hi Sam Thanks for your advice :) I've made a small flowchart: Is this the right approach? So client 1 has 3 send threads. i assume that i have to put these in a thread pool so that the send operations are queued. Can send and receive operations be performed at the same time? Thanks in advance.

JR · Answer

Hello Sam Thanks for your reply. I've been studing the code from the codeproject site but i think this is to complexed for my application. The thing is I am building a robot that has a small PC (probably the Foxconn NT-A3500) that has a Netduino Plus (based on c# .NET Micro) connected to its ethernet port ( http://www.netduino.com/netduinoplus/specs.htm ). The robot PC + Netduino will serve as three TCP clients (two clients on NT-A3500). From my PC the server/host will be running with a wire connection to a wireless router (linksys). The robot and netduino will be controlled using the wifi connection of the NT-A3500. The netduino Plus client will receive direction commands from the PC server and send back diagnostic results (motor speed rotary encode RPM and current usage of the motors). This connection has to be bidirectional or is asynchonous better? The Foxconn PC will have 3 webcams connected to its USB ports every webcam will send pictures with a speed of 10 FPS (so 30 FPS in total) to the server using its own tcp connection (I think this is better this way?). Another client on the PC will take care of handling commands and sending diagnostic results) I've seen a client examples for the Netduino and they are very basic (based on the socket class) and I think that this client/server solution doesn't have to be so complex because only a few client connections have to be handled (I think this is enough for a threadpool server). Any suggestions? Thanks in advance.

Sam Hobbs · Answer

Anything asychronous will be in a different thread. Events such as SocketAsyncEventArgs.Completed are executed in another thread. You are correct that it is not obvious and the documentation does not make it clear. If you were to try to directly access a control in a form in an event such as SocketAsyncEventArgs.Completed then you are likely to see the other thread; you are likely to get an error.

JR · Answer

Hello HermanthKumar V Thanks for the MSDN link. Is it correct to say that this is the better/optimized way to do asynchronous tcp socket programming? I found the following nice example on how to use the SocketAsyncEventArgs Class: http://www.codeproject.com/KB/IP/socketasynceventargssampl.aspx I'll study and try this one. Thanks.

Hemant Kumar · Answer

This class was specifically designed for network server applications that require high performance.  As I understand you are a client here having only a single connection. Data on this connection arrives in order consumed by a single thread. You will probably loose performance if you instead receive small amounts on separate threads just so that you can assemble them later in a serialized - and thus like single-threaded - manner . Much Ado about Nothing. You do not really need to speed this up you probably cannot. What you can do however is to dispatch work units to other threads after you receive them. You do not need SocketAsyncEventArgs for this. This might speed things up. As always measure & measure. Also just because you can it does not mean you should. If the performance is enough for the foreseeable future why complicate matters?