LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

tcp listen accepts multiple simultaneous connections even when closed

LV 6.0.2, win 2k

I am trying to set up a server that will recieve data from multiple clients. If I set up a TCP listen vi on the server, then I have found that any (or the same) client can open multiple connections on this port and send data to it even though the server has only called the TCP listen VI once and only has a reference for the first connection. The subsequent connections seem to be accumlating in the port buffer and the data can in fact be retrieved with subsequent calls to TCP listen on that port regardless of whether the client has closed the connection long ago and forgotten about the transaction.

This could perhaps be considered either a feature or a bug. For me it is undesirabl
e. I would prefer that attempted connections to the server were rejected if the server is not actually actively listening on the port. Otherwise clients can easily flood the port.

Is there some way to control this behaviour, or perhaps a completely different approach? or is there some way to control the port settings such as buffer size or max number of connections allowed, and a way to clear the buffer without processing all the connections?

Thanks in advance for any thoughts.
0 Kudos
Message 1 of 4
(5,883 Views)
Steve,
This is an expected behavior with TCP. TCP Listen listens for clients, and stores the open references to a buffer. You do not have control of this buffer. TCP Read references the buffer with data in it, and you can setup this buffer size.
When several clients send requests to the server, the server will execute them in the order in which they were received. It doesn't matter if the client closes the connection in the meantime, because the server already received that request. However, if the server closes the connection after reading the first request, then it will not process the rest of the requests waiting in the queue.
When you leave the connection open on the server side, you can receive multiple commands this way, but it also blocks
other clients from connecting until the current client disconnects. You can restructure the block diagram to handle multiple clients simultaneously, by running two loops simultaneously. One loop would continuously wait for a connection and then add the connection to a synchronized queue. The second loop would check each open connection and execute any command that has been received.
Please see the attached VI.

Zvezdana S.
Naional Instruments
Download All
0 Kudos
Message 2 of 4
(5,883 Views)
Thanks for the comments.

I don't seem to get the same behaviour you describe.

When you say 'if the server closes the connection after reading the first request, then it will not process the rest of the requests waiting in the queue'. I find that after the server closes the connection (with TCP close connection) then there can still be a huge backlog of connections to the same port (requests) which are still waiting to be processed. Another call to TCP listen retrieves one of the old ones, it doesn't wait around for a legitimately new request from a client.

Where you say 'When you leave the connection open on the server side, you can receive multiple commands this way, but it also blocks other clients from connecting until the curre
nt client disconnects'. This is in fact my main difficulty. Even with a connection held open other clients (or the same client) CAN make other connections and send data through that connection. This then backs up if the server is not processing them faster than recieving them.

I've attached vi's which should demonstrate the issue.

I couldn't check your vi's. I'm missing the EOC error.vi and one other I think. Ultimately I hope to do something similar with multiple open connections, but still need the server to be able to refuse connections if it wants to. Something I don't seem to be able to do. The connections just keep coming regardless of how the server is set up.

Thanks again.

Steve
Download All
0 Kudos
Message 3 of 4
(5,883 Views)
I'll just add one further comment to wrap this up in case someone else in interested;

All I needed to know is that once a listener is activated it will continue accepting connections - until it is closed. It appears that to close a listener one can use the 'close TCP connection' vi - if you just feed in the listener reference instead of a connection reference. If the help files had mentioned this or if the vi was actually called 'close connection/listener' I might have worked this out sooner. Maybe its obvious to everyone else.

S
Message 4 of 4
(5,883 Views)