listening on open ports

[altenbach]

---

exo wrote:
My network utility (MAC) tells me I have open ports but LabVIEW won't let me listen to them.
What's going on?

---

Form the typical definition, an open port is a port where a service is listening. This means the port is in use an cannot be used by other programs.

I think you have a complete misunderstanding of TCP/IP networking.

If you try to connect from LabVIEW to the other computer, you simply need to know the port number. For well known services such as ftp, you should try the standard port (21 for ftp). There are 2^16 different ports available for TCP, and the same for UDP.

If you try to connect from a different computer to your LabVIEW application, your LabVIEW code needs to listen on a certain port and the other application needs to know that port number in order to connect. In addition, your programs need to follow a predetermined communication protocol.

[exo]

But that's the problem, as far as I know the send and the listen port were the same. Are there diagnostics I can run to check that I am doing it correctly?

[exo]

The scan port utility tells me port 6000 is open but the Internecine Avoider.vi won't allow the connection.

[altenbach]

First of all, why do you specify a net address. Do you have multiple interfaces? It is a bad idea to hardwire the server address, because the VI will immediately stop working when moved to any other hardware.

---

exo wrote:
The scan port utility tells me port 6000 is open but the Internecine Avoider.vi won't allow the connection.

---

How do you run the listener? It currently listens for one packet, then quits, closing the connection. You need to place a loop so it continues to listen for more packets. (Don't use the "continuous run" button!!!)

I assume that "Internecine Avoider.vi" is the client trying to connect. It can only try to connect, but has no say in allowing or disallowing the connection. This is up to the server. Since the server stops after one data packet, the connection gets killed very quickly. Cal you also show us the code for the client?

Instead of blindly hacking around with misguided efforts, have a look at some of the examples that ship with LabVIEW, then try to modify them for your purpose.

I would suggest to start with the following two examples:

• simple data client.vi
• simple data server.vi

Open the example finder and look at these examples. See how far you get. Good luck! 🙂

[exo]

I want to listen so I used the TCP listen vi which listens at a specified port. This is what I want to do, I want to listen for a signal from another computer on that port. If you look at the block diagram for the TCP Listen vi, you will see a vi called the Internecine Advisor which is telling me that I can't listen a port I know to be open.

TCP Listen
Creates a listener and waits for an accepted TCP network connection at the specified port.

The client code is attached. The actual code doesn't send the file, just sends a byte.

[RavensFan]

Exo,

Definitely take Altenbach's advice and work through the TCP examples first to understand how the protocol works.  There is no way to make something like this work with just a stab in the dark with the TCP functions.  You need to create something for both ends.

What computer has the IP address 198.202.125.164?  The only way the code will work is if that IP address is the one for the machine your VI is running on.  It isn't necessary and is only used (as listed in the help file for TCP listen if you have more than one network card and only want to listen on a specific one.)

Christian, that title of Internecine Avoider got me curious, so I dug down through the subVI's of TCP listen and looks like it checks for valid ports and maintains a list of connections.

My guess at the cause for that error is that the IP address put in was for the other machine, not for the one the VI is running on.  When internecine advoider tried to look up that port under that IP address, it threw and error because that IP address doesn't exist on the machine.  I got the same error when I first ran the code.  I realized it was because that IP address was hard coded in, and of  course it is a 1 in 2^32 chance that my PC would have the same IP.

Message Edited by Ravens Fan on 02-16-2008 04:57 PM

[exo]

The address is correct. It is one of a few on a private net that includes both the sending and receiving computers. I have also read that the input for a IP address is to be able to differentiate between two address on the same machine; but it doesn't matter. Taking that out doesn't help matters.    I also think I mentioned, that if I go to the network utility and do a port scan for that IP address I get open ports that the internecine advisor won't accept.  Maybe it just doesn't like the form of the IP adress system. Does it work for any of you?  You have my send code.

Also, I my own defense, I have read the material. I have several vi's talking and listen to other devices using TCP/IP  And the help does say that it listens to a connection. It doesn't say that the connection doesn't have to come from LabView. 

[altenbach]

---

exo wrote:
 I also think I mentioned, that if I go to the network utility and do a port scan for that IP address I get open ports that the internecine advisor won't accept. 

---

As I said, if a port scan shows a port as open, that port is already in use by the system and is no longer available for use by LabVIEW. You need to select an unused port.

[RavensFan]

---

exo wrote:

Does it work for any of you?  You have my send code.

---

Your VI first gave me the same error you got.  But I realized it was because of the hardcoded IP address.  Once I deleted that, I had no errors but the code seemed to hang.  That because of the infinite timeout in the TCP/IP listen.  Since I didn't have any program trying to send something to my PC on port 6000, that made sense.

As for your C file, I don't have any means of running C code, and as for looking at it.  C code usually looks like gibberish to me.

I decided to open up the example file TCP communicator -Active VI.  I ran your listen code.  Then I set that one to port 6000 and ran it.  When I entered a character into its input line, your code ended and returned that character.

All seems to work.

[exo]

Thanks guys.

I missed the part about an open port allready being is use but I did try ports that weren't in use.  I look at it again on Monday.See if I can put it all together.