Socket help

[NeilA]

I have a server that listens on a port (27000) that I need to replace to fit in with my new system. The client code can't change. I have found a few articles that say you can build a server using the LabVIEW TCP primitives but having little knowledge about what is exchanged between client and server and how it all works. I have tried using the solution found in this link (read cutting a corner lol).

http://forums.ni.com...&thread.id=1941

I am unsure how to set the Local IP there doesn't seem to be a way to do this, only a way to read it. This is going to be a problem. As at first this was setting itself to 127.0.0.1 which is fine, but now it seems to use 0.0.0.0 which means the client app wont connect. From what I can read about the winsockcontrol activex component you should be able to set the IP but maybe I am missing something(I have not done much more than the Int2 ActiveX training).

I dont know how to monitor the client handshaking data but I am lead to believe it is winsock standard.

I don't know if any of you have seen this code before and know what the problem may be or have a LabVIEW primitive solution, but any help would be greatly appreciated.

Many Thanks in advance!!

Neil.

[ned]

It looks like the code in that post on the NI forums is quite old, and you definitely don't want to use Winsock directly (or through ActiveX). There are shipping examples of creating a server, under Networking->TCP & UDP, which use the LabVIEW primitives.

As far as determining the protocol that your client uses to exchange data, you'll either need to find some documentation, or spend some time with a packet sniffer (I'm sure someone else can recommend one for Windows, my experience is with tcpdump on unix) to try to reverse engineer the protocol. There is no such thing as "Winsock standard" handshaking.

[Mark Smith]

I have a server that listens on a port (27000) that I need to replace to fit in with my new system. The client code can't change. I have found a few articles that say you can build a server using the LabVIEW TCP primitives but having little knowledge about what is exchanged between client and server and how it all works. I have tried using the solution found in this link (read cutting a corner lol).

http://forums.ni.com...&thread.id=1941

I am unsure how to set the Local IP there doesn't seem to be a way to do this, only a way to read it. This is going to be a problem. As at first this was setting itself to 127.0.0.1 which is fine, but now it seems to use 0.0.0.0 which means the client app wont connect. From what I can read about the winsockcontrol activex component you should be able to set the IP but maybe I am missing something(I have not done much more than the Int2 ActiveX training).

I dont know how to monitor the client handshaking data but I am lead to believe it is winsock standard.

I don't know if any of you have seen this code before and know what the problem may be or have a LabVIEW primitive solution, but any help would be greatly appreciated.

Many Thanks in advance!!

Neil.

To look at the TCP/IP traffic, Wireshark is the defacto standard for Windows

http://www.wireshark.org/

As far as setting the IP address on the server (I think that's what you mean), you can use Control Panel->Network Connections->Local Area Connection and then right click for properties and change the IP address to a static one.

Lastly, the XML-RPC project in the Code Repository

http://lavag.org/ind...ads&showfile=66

has an example of a LabVIEW server.

Mark

[Rob Calhoun]

I am unsure how to set the Local IP there doesn't seem to be a way to do this, only a way to read it. This is going to be a problem...

You generally do not need to set an IP address when you create a server, just a port. The address input is there only so that you can force a machine with multiple IP addresses to listen on only a specific IP. The default is "listen on all IP addresses".

As others have said, there are good examples of how to use the TCP primitives. Basically you create a listener, wait on the listener for a connection, then service the connection. The one thing that is not very clear is that you do not need to create a listener more than once; one listener can handle an unlimited number of connected clients. Typically you pass a cluster with the TCP refnum and other data (e.g. "New Cnx") to a new re-entrant process that runs top-level so that the listener thread can go back to the wait-on-listener state.

The code below is simpler than that; rather than spawn off a server process, it just dumps a datetime message to whomever connected on port 27000 (via e.g. "telnet localhost 27000" and then hangs up the TCP connection. With this type of design you can only have one client connected at a time. Once done with the current client, it will go back to waiting on listener. To exit the program cleanly we use the close TCP function to close the listener, causing Wait On Listener to error out.

-Rob