A TCP/IP connection policy (cvi 6)

[DavidLee]

I want to make such a TCP communication policy :
Once the TCP server receiving a TCP_CONNECT event from a client ,application can create another thread to process the proceed transaction ,thus ,I can use one TCP server to handle many client .But I am not sure if can use multithread to do this ?

David

[Chris Matthews]

You wouldn't want to handle the TCP messages in separate threads since they are all going to be coming in on the same TCP port, it would be futile to have multiple threads trying to read from one stream. Instead you would want to create worker threads to process the messages as they come in. Here is what I would do. When you get a message from a client, (aka TCP_DATAREADY event) spawn off a thread to process the message (using CMT_ScheduleThreadPoolFunction). That way, your messages will be processed in a worker thread and the main thread that's reading the TCP messages will be ready for the next message. This would work much more efficiently than a model of 1 thread per client, since most of those threads would probably be idle most of the time. This meth
od would only create more threads as they are needed because it would create new threads only when your TCP messages are coming in faster than you are processing them.

Best Regards,

Chris Matthews
National Instruments

[DavidLee]

Chris,

As your idea , I am still not sure how to distinguish the different conversation handle .I hope once there is a TCP_CONNECT event occured , I can capture it immediately , and know which client loggin ,then process the proceed conversation in another thread. Please give a detail info . Thanks.

David

[Chris Matthews]

As I said before, processing each client in a separate thread designated for that client is not the most efficient way. The best way to use multithreaded programming to handle the messages would be to use message processing worker threads that are NOT tied to specific clients, that way it can scale up and down based on the activity of TCP messages, not just on the number of clients.

You can do that though if you want, but the architecture would be more difficult. What you would do, is on the TCP_CONNECT, store the conversation handles in an array and also have an array of ints that are activation flags for your threads. Then ,create a thread for each conversation handle that is idle (while loop checking for activate flag to be set), storin
g the thread IDs in an array with the same indexes at the conversation handle array.

Then, when you get a DATAREADY message, check the conversation handle, find it in the array, then activate the thread (set the activate flag variable for that thread) for that conversation and send it the message contents with a thread safe variable or a thread safe queue.

Again, not as efficient as message worker thread model, but it would work.

Chris

[DavidLee]

Thanks Chris. Again , I ask another lowclass question :as the message worker theory , how to determine a client has been offline so that I can release the corresponding thread ? because the conversation handle is not concerned in this process mode.

David

[Chris Matthews]

You will get a TCP_DISCONNECT in the server whenever a client goes offline. You can trigger off this event to know when to discard the handle and the thread.

Chris

[DavidLee]

Hi Chris ,

As your idea , I have modifyied the example of TCP server , which is located in cvi\samples\tcp . I hope once the TCP_DATAREADY occured ,application can spawn off a thread function ,which will send the message of "receive OK" to the client immediately , the thread function is named "TcpWriteOK" ,to do this ,the callbck function "TransmitCB" is closed by me .For keep the connection , I pass the handle address to "TcpWriteOK()". However , when executing it , it always return an error message "No connection established " . If it can not pass the conversation
handle to a thread ? please see the attached ,and the breakpoint is placed on the line of 238 .

David

[DAD]

This thread has been idle for a while but this is along the same lines. The basic question is: How long is the handle received by a TCP callback valid?  I am trying to set up some server code that upon receipt of a TCP_DATAREADY event will pass information via a thread safe queue (thereby generating another callback) to a routine that will generate the response.  This keeps the time spent in the TCP callback to a minimum.  If I pass the handle received by the TCP callback through the queue, will it still be valid in the queue callback for use in TCP writes to send data back to the client?