How to use TCP client instead of Telnet client

[pravin]

Hi all,

I have remote application (i.e. telnet server) using command prompt I use telnet client for example telnet 127.0.0.1 9001 and sending command to the application. And it works fine but I want to use labview based telnet client using TCP to send command to the remote application.  

By using command prompt (telnet client) i can send command directly to the application, but I have tried with TCP and it can't give me proper output please find below code snapshot and please reply.

 

 

 

Thanks

Pravin

 

 

 

 

 

 

 

[ned]

Are you sure you're sending the correct command over TCP? When you connect over telnet, do you have to hit Enter after typing the command? It might be as simple as adding an end-of-line character (carriage return, new line, or both) to the end of the string that you send over TCP.

[Rolf Kalbermatter]

Are you sure you're sending the correct command over TCP? When you connect over telnet, do you have to hit Enter after typing the command? It might be as simple as adding an end-of-line character (carriage return, new line, or both) to the end of the string that you send over TCP.

 

In addition to what Ned says, Telnet is a protocol in itself that sits on top of TCP. So just going to send the string that you normally enter in the Telnet prompt definitely will not work! You have to implement the Telnet protocol (which is quite simple BTW) on top of the TCP primitives too. However the Internet Toolkit contains a full Telnet client library.

[Phillip Brooks]

In LV2012, the Telnet API has been deprecated, but is available for download (not supported).

 

http://digital.ni.com/public.nsf/allkb/EB34E86CE3AD08D686257A2B005482FD

[ensegre]

Zombie resurrecting.

I'm in the same situation, downloaded the deprecated, and see that the interesting VIs are password protected. With due time I can perhaps work my way out, but otherwise can someone suggest me a quick wrapper just for sending command strings and receiving replies?

TIA, Enrico

[crossrulz]

As long as you don't need the command codes, just look to the TCP Client and TCP Server examples already built into LabVIEW.  Telnet only gets complicated (at all) when the command codes are used.

[ensegre]

You mean plain tcp read/write VIs? I am wondering. Searching just a bit more I found that I can use VISA read/write with resource id TCPIP::<ip>::<port>::SOCKET; what I'm fighting with now is how my instrument behaves in term of holding a failed connection and refusing a new one. I need to disentangle a bit the message protocol itself and the odd behaviour around it.

Edited July 2, 2018 by ensegre

[Rolf Kalbermatter]

VISA TCP Socket is in principle the same that you also get with the native TCP nodes.

Advantages:

- VISA implements more in terms of automatic message termination recognition

- VISA may seem more familiar to you if you have excessive experience writing instrument drivers

Disadvantages:

- You need to have NI-VISA runtime installed on the target system and the according TCP passport driver. If you use the native nodes, everything is included in the standard LabVIEW runtime.

 

For the rest the VISA Write is pretty much equivalent to the TCP Write and VISA Read is similar to TCP Read. Therefore implementation of any protocol on top of TCP/IP will be pretty much the same independent if you use VISA or native TCP.

Edited July 2, 2018 by rolfk

[ensegre]

Thanks for confirming, Rolf. I also suspect that in addition to that is that ::socket is a windows only concept, or perhaps I don't have a sane VISA on my linux dev.

I'm actually progressing with plain TCP. I'm only stumbling in my device sometimes hanging and refusing connections, this was what confused me at the beginning. A matter of programming so to avoid the condition which causes the lock, rather than abruptly power cycle the device. Anyway, now seemingly related to the particular device and not to the  communication layer.

[crossrulz]

1 hour ago, ensegre said:

I'm only stumbling in my device sometimes hanging and refusing connections, this was what confused me at the beginning.

You might want to monitor the communications with something like Wire Shark.  You might find the instrument sent a command code and is waiting for you to confirm it.

[Rolf Kalbermatter]

As crossrulz said, definitely use something like Wireshark to debug the actual communication. VISA supports TCP socket communication on all platforms it is available. But installaiton on Linux may be not always seamless.

I always prefer to use the native TCP nodes whenever possible. VISA is for me only an option if I happen to write an instrument driver for an instrument that supports multiple connections such as serial and/or GPIB together with TCP/P. 

[ensegre]

yes, wireshark with plain telnet should be easy. I got the impression that I ended in a case of "device refuses to admit the connection broke, and refuses a new connection because outbuffer is full", whatever. If so, avoidable with programming by not asking too much at once. For the rest, I'm probably there, by now. Pfeiffer Maxigauge TPG 366, btw.

Thx both for the feedback!

Edited July 2, 2018 by ensegre

[ensegre]

Still shamelessly hijacking. So I'm polishing this VI, using basic tcp/ip, and observe the following. I have occasional network disconnections, and work around then attempting to reconnect, if tcp read gave error.

I'm testing it on various PCs, with the device connected back-to-back or through some amount of intranet. Disconnections are easily simulated by pulling the ethernet cable and reattaching.

Now my consistent observation is: one linux machine, reconnection seems to work robustly well. Three windows machines, quite often re-open TCP fails with Error 56. Not even restarting labview helps, only power cycling the instrument does. [I haven't yet had the chance of trying when both win and linux are on the same intranet]. Any idea why this is happening, is windows basic tcp different? Can I force some kind of port release harder than with tcp close?

 

[ShaunR]

Just spit-balling but you may be seeing the effects of lingering. (or not lingering as the case may be)

You can try setting the linger ON with a zero time-out (using setsocketoption) which will cause an abortive close. There is a VI that enables one to obtain the underlying raw TCPIP connection that can then be used by setsocketoption. It's usually used for TCP_NODELAY

[ensegre]

[after some more inconclusive tests with another linux laptop back-to-back and intranet, and dumb wiresharking].

Maybe. I mean, you're not suggesting to disable Nagle (that would effect all other traffic from the host NIC, probably not good), just to get the handle from that VI. I'll have to educate myself, e.g. https://stackoverflow.com/questions/3757289/tcp-option-so-linger-zero-when-its-required. I wish I could defer it to a rainy day, unless hangups with that device become frequent.

Oh, is this in the way?

On 6/28/2018 at 4:39 AM, smithd said:

Today I learned that labview aborts connections immediately even if you dont wire in abort, because...

" abort is reserved for future use. " (help)

 

Edited July 4, 2018 by ensegre

[ShaunR]

2 hours ago, ensegre said:

just to get the handle from that VI.

Well. The VI is in vi.lib but the Nagle vi uses setsocketoption so it would just be a case of changing the level to SOL_SOCKET, the optname to SO_LINGER and supplying a cluster of of 2x UINT16 for the optval.

Edited July 4, 2018 by ShaunR

[Rolf Kalbermatter]

3 hours ago, ShaunR said:

Well. The VI is in vi.lib but the Nagle vi uses setsocketoption so it would just be a case of changing the level to SOL_SOCKET, the optname to SO_LINGER and supplying a cluster of of 2x UINT16 for the optval.

But watch out! The socketoptions are NOT compatible between WinSock and Linux. There are even differences in the actual numeric values for the SOL_ and/or SO_ constant names between different Unix implementations. And some of the options have different datatype between Windows and Unix.

[ShaunR]

7 minutes ago, rolfk said:

But watch out! The socketoptions are NOT compatible between WinSock and Linux. There are even differences in the actual numeric values for the SOL_ and/or SO_ constant names between different Unix implementations. And some of the options have different datatype between Windows and Unix.

The only difference is 0x1 for Linux (SOCK_STREAM) and 0xFFFF for windows (SOL_SOCKET). For Linger, Buffer sizes and Nagle the parms and constants are identical between platforms. Besides. The issue he is having is under windows as far as I can tell.

[ensegre]

Note taken. For the moment though I took the path of calling Pfeiffer service. It would make more sense to me that their firmware is buggy, failing to release a disconnected port. After all this device acts as a telnet server, when it refuses incoming connections I would blame it rather than the client. Oh, and no, today I had occurrences when neither windows nor linux could connect, as well as ones where disconnecting and reconnecting the cable a few times didn't lose it. Either I'm missing something in this tests, or something is fishy. 

Edited July 4, 2018 by ensegre

[Neil Pate]

Turning off Nagle affects all the traffic on the NIC? I thought it was just for the particular socket connection. 

[Rolf Kalbermatter]

On 4-7-2018 at 4:49 PM, Neil Pate said:

Turning off Nagle affects all the traffic on the NIC? I thought it was just for the particular socket connection. 

It depends how you do it. There are many registry hacks to enable and disable various features also for Winsock. That way you force it indeed even for all network interfaces. But the setsocketopt() works on a socket (the underlaying socket driver handle that a LabVIEW network refnum encapsulates). That way you only change the option for that specific network connection.  

Edited July 7, 2018 by rolfk

[Rolf Kalbermatter]

On 4-7-2018 at 4:19 PM, ShaunR said:

The only difference is 0x1 for Linux (SOCK_STREAM) and 0xFFFF for windows (SOL_SOCKET). For Linger, Buffer sizes and Nagle the parms and constants are identical between platforms. Besides. The issue he is having is under windows as far as I can tell.

I didn't check for linger but there are several others that definitely differ. 

[ShaunR]

5 hours ago, rolfk said:

I didn't check for linger but there are several others that definitely differ. 

Quite probably. But I have a VI lib for setsockopt that works on Windows, Linux and Mac for the aforementioned calls. The knarly part is the path to the libraries that implement it.

[ensegre]

On 7/4/2018 at 5:32 PM, ensegre said:

Note taken. For the moment though I took the path of calling Pfeiffer service. It would make more sense to me that their firmware is buggy, failing to release a disconnected port. After all this device acts as a telnet server, when it refuses incoming connections I would blame it rather than the client. Oh, and no, today I had occurrences when neither windows nor linux could connect, as well as ones where disconnecting and reconnecting the cable a few times didn't lose it. Either I'm missing something in this tests, or something is fishy. 

Update just for the record - a number of phone calls to the representatives, "so explain me again what error do you get" "Did you read my email?? When do I get an updated firmware?" I got this new firmware, whose release note spells

Fixed Problems
--------------
- some improvements in Ethernet communication

and the problem disappeared...