Difference between Thread pool and asynchronous tcp server

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.

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

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.

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. 

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.

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.

1. 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?
2. 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.

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.