How do I connect multiple telnet clients to a telnet server in LabVIEW?

[clnorris]

Good afternoon,

I'm writing a telnet server in LabView 6.1 that needs to handle multiple clients. To do this, I modified the "viserver\runvi.llb" example to use the telnet VI's from the Internet Toolkit instead of the TCP VI's. Then I changed the Open VI Reference to point to my telnet handler. Right now my handler just echoes the characters received from the client.

My software works ok for the first connection. After the server accepts two or more connections, characters typed in one client get echoed to all clients. In addition, only one client will accept characters at a time. The client accepting input changes randomly every few seconds as characters are entered.

Has anyon
e gotten the telnet VI's to run in parallel? Not sure if they are thread-safe or not. If you have some experience with this, I have attached my llb if you think you can help.

Thanks!

Chris Norris
Carrier Access Corp.
cnorris@carrieraccess.com
(303) 218-5826

[Jeremy Braden]

Do you think that you might need to use different ports for each of the remote connections?

[clnorris]

I tried modifying the VI so that each time a client connects, the port that the server listens to gets incremented before it waits for the next connection. This did not seem to affect the behavior.

I don't think it should matter though, since I've always been able to telnet to standard ports on other machines (for example, port 25 on smtp servers or port 110 on POP3 servers).

Maybe I'm misunderstanding something, but since these machines handle lots of connections simultaneously at a standard port, I figure I should be able to write a similar app in LabVIEW, even implement the mail servers.

Thanks for the feedback!

[John Lum]

I don't think there's a problem with the TCP/connection portion of things. My feeling is that the problem is lurking somewhere in the timing of the application, or in the way LabVIEW task scheduling/multitasking is working compared to the way you expect it to work.

For instance, I'm wondering why you stuck with 25 seconds (25000 ms) as the timeout value for the Telnet Read in Telnet Handler.vi. I assume you're expecting LabVIEW to quickly "sleep" that while loop and move on to check on the while loops of any other Telnet Handler.vi instances that might have been spawned as a result of connection requests from other remote clients.

Instead, it seems to me (on my system, anyway, with three simultaneous connections active) that LabVIEW is not cyc
ling through the other Telnet Handler.vi instances as you expect, but is only getting to them to read a byte at a time each time the main loop iterates in response to a byte appearing from the first of the three remote clients.

If you change the Telnet Read timeout to 50 ms instead, the behavior is closer to what you might expect, but still not perfect.

Because timing/threading/scheduling is a complicated subject in LabVIEW, I'm going to give LabVIEW the benefit of the doubt and assume it's operating as designed. Maybe someone else can provide more insight into what's happening in this particular case, and whether reentrancy or something else is affecting things.

One option I would consider if I were in your shoes: program a simpler version of things that mimics Date Server.vi and cycles through a queue of connections to service them without relying on spawning new reentrant instances of a handler VI.

I realize that your version of things (along with the reentrancy example
that ships with LabVIEW) is expressly intended to handle this daemon-style situation, but simpler may be better for the purposes of debugging and development ease.

My two cents,
John Lum
National Instruments

[clnorris]

Hi John,

I was indeed hoping the Telnet Read would sleep and allow the other instances to continue. I tried changing the timeout to 50 ms, and now it works correctly on my machine, though a bit slow. This might be ok.

The reason I would rather not service all connections in one VI is that I'm implementing a command line interface. I don't want the complexity of parsing multiple command lines to be visible to anyone (including my lazy self). Instead, I'd rather debug a single-user version and just run it multiple times. I'll be happy if I can get 30 instances running.

I wonder if anyone has written a LabVIEW BBS or MUD.

Thanks for the feedback!

Chris Norris
Carrier Access Corp