non reentrancy for TCP/IP VIs.

[sumitrishi]

I am trying to write a server program that caters to multiple clients. The clients are being made to wait in turn when the data has to be sent back to them. The requests from client are handled by the server pretty
much in the desired multi threaded fashion.
Is it that the every instance that is spawned by the server to handle a particular client request(this is done using reentrancy) is rendered useless because tcp/ip VIs are not re-entrant .Please assist me in correcting my understanding. Also suggest me how to make the server actually catering to multiple clients if tcp/ip VIs are actually a limitation.

Calling LabviewGuru(s) to help.

[rolfk]

sumitrishi wrote:

> I am trying to write a server program that caters to multiple clients.
> The clients are being made to wait in turn when the data has to be
> sent back to them. The requests from client are handled by the server
> pretty
> much in the desired multi threaded fashion.
> Is it that the every instance that is spawned by the server to handle
> a particular client request(this is done using reentrancy) is rendered
> useless because tcp/ip VIs are not re-entrant.

Are you sure you see trouble at the TCP Read and TCP Write level? As far
as I can say, they are highly asynchronous and do not block other
instances of VIs calling them as well, at least for different refnums.

Which version of LabVIEW are you using?

Rolf Kalbermatter

[sumitrishi]

Rolf,

I am not sure if the trouble is at TCP read and write. I have attached my VIs and a hierarchy diagram for you to understand my doubt better.They are in a different discussion thread with Mads . I am sure you should be able to see them from there.

I am using LabVIEW 6.1 .

Thanks
-Sumit

[ryank]

The VIs and other discussion forum thread are here:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000024D80000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0

I would suggest continuing this thread there so as to avoid duplicates.

Regards,
Ryan K.