More doubts on: 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; and that exactly is my problem. The requests from client are handled by the server pretty much in the desired multi threaded fashion.
Is it that 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 non re-entrant. Please assist me in correcting my understanding. Also suggest me how to make the server actually catering to multiple clients if reentrancy is a limitation for tcp/ip VIs.

Further to the question asked above do I need to open different ports for the mu
ltiple client and server communication to happen simultaneously.May be using the same port is what I need to avoid and problem is not with the TCP/IP VIs.Please help.

[Mads]

How exactly do you spawn request handlers? Do you call a reentrant handler VI dynamically with the run method?

It's possible to have multiple connection handlers that handle requests in parallell, I do that in several of my client-server applications. All clients connect to the same port, that's not the problem.

There must be something in the architecture you have that prevents this from working; is there e.g. a reply generator that may halt the other handlers when it's busy with the request from another handler?

[sumitrishi]

>>How exactly do you spawn request handlers? Do you >>call a reentrant handler VI dynamically with the run >>method?

Yes.

>>There must be something in the architecture you have >>that prevents this from working; is there e.g. a >>reply generator that may halt the other handlers >>when it's busy with the request from another handler?"

I am attaching the hierachry diagram below all the VIs in the child process are re-entarnt except for the custom controls at the bottom. And I am not sure how to make them instance specific. Could they be common resources on which handlers are waiting in turn.

I have attached the server source also so that you can understand my doubt better. I really appreciate your effort in helping me out.

[Mads]

The server part is OK. I see the session handler opens a database, my guess is there is something there that prevents parallell replies. If you strip down the session handler to just reply with a string generated in the handler; are things still not able to run side by side? If it's not could you post the stripped handler?

[sumitrishi]

I would have to try it ( I mean stripping of handler).
But I am not sure if I would be able to feel any difference until unless the size of the string returned by the handler is of considerable size and would make the other handlers wait.

As far as database is concerened I have the admin privileges for it and I can monitor the number of connection and every time a new client comes I can see a new session getting reflected.I was just wondering if it has anything to do on the client side I was trying to set the operation mode for tcp read to immediate but to no avail.

[ryank]

Just because you are getting a session for each client does not mean that they are all working simultaneously. Databases ususally implement locking for records, so it may be that the records you are accessing can only be used by one session at a time.
Also, I've attached an example I found lying around on using multiple clients with a server, this one does use a port for each client. You could try it out and see if it performs any better.

Regards,
Ryan K.

[rolfk]

ryank wrote:

> Just because you are getting a session for each client does not mean
> that they are all working simultaneously. Databases ususally
> implement locking for records, so it may be that the records you are
> accessing can only be used by one session at a time.
> Also, I've attached an example I found lying around on using multiple
> clients with a server, this one does use a port for each client. You
> could try it out and see if it performs any better.

I'm pretty sure the database is the culprit. That or one of the layers
from ADO-DAO-ODBC-database. There should be no need to use different
ports for each client in the server other than making them
distinguisable from the client side.

Rolf Kalbermatter

[sumitrishi]

I think database locking and all does not come into picture till the time you are just reading the data. As a matter of fact in my handler I try to run a stored procedure which has data insertion but it happens only in oracle global temporary table. These tables are used for parallel run and insertion can happen simultaneously in different sessions, in fact each session gets it own copy of global temporary tables. If I try running my stored procedures from two different instances of TOAD(interactive utility to work with oracle) the stored procedures run parallely independent of each other.

I just tried running TOAD and my program together and they did run without problem. Indication oracle for ODBC driver also is ca
pable of multithreading.

However I am not so sure about the way 'oracle ODBC driver' and labVIEW interacts?

[rolfk]

sumitrishi wrote:

> I think database locking and all does not come into picture till the
> time you are just reading the data. As a matter of fact in my handler
> I try to run a stored procedure which has data insertion but it
> happens only in oracle global temporary table. These tables are used
> for parallel run and insertion can happen simultaneously in different
> sessions, in fact each session gets it own copy of global temporary
> tables. If I try running my stored procedures from two different
> instances of TOAD(interactive utility to work with oracle) the stored
> procedures run parallely independent of each other.

TOAD probably does not use ODBC, DAO, or ADO at all but directly
communicates throug
h the native Oracle network protocol. I would be
surprised if they can't handle concurrent connections on that level for
such a commercial grade application.

> I just tried running TOAD and my program together and they did run
> without problem. Indication oracle for ODBC driver also is capable of
> multithreading.

Multithreading of course, otherwise it wouldn't run with ADO, DAO but
that does not mean that the ADO/DAO layer to access an Oracle database
is guaranteed to not use some sort of lock during extraction of the
data, which in these APIs is usually the most time consuming part anyhow.

> However I am not so sure about the way 'oracle ODBC driver' and
> labVIEW interacts?

In the new Database Connectivity Toolkit, it accesses the Active X Data
Object (ADO) interface. This interface then either uses an OLE-DB
provider to communicate to a particular database or if there is no such
provider uses a gateway to access the ODBC driver for that database. I
think there is also
a translation to DAO, the previous object oriented
Microsoft database interface before ADO, for such providers.

So there are a number of places where a restrictive lock could limit
parallel operation severely.

Rolf Kalbermatter

[sumitrishi]

Thanks Rolf that was pretty informative.Furthering my efforts I was looking at the property node for connection interface I have a feeling that if anything has to be done it should be done at the point when the connection is made . There is this particular property called 'mode' and one of the constant settings for it is 'adModeRecursive' . Could that be the place for me to look at ? Somehow for me setting it has been generating error .Can you please tell me what actually is 'mode'. I am appreciative of all your help. -Fellow ex NI ( I was with India Branch, although I spent most of my time working with CW++)