tcp open connection problem while parallel tcp communication

[joernheit]

Thanks a lot Rolf for the valuable insight. I do understand that semaphores are required sometimes. Up to now my perspective towards networking with labview was kind of toplevel : listen, open, read/write, close thats it !. Now I see the  necessity to increase the knowledge.

I tried your Network Library some weeks ago but ran into problems. Now I don't know why I didn't come back to you with a proper error description. Sorry for that, but you can count on me for beta testing if you are ready with the update. And of course your work is very much appreciated. There must be tons of manhours in the libraries, not only the networklib but also lua, etc.

@mark: I don't mean simply replacing TCP with UDP functions, but to realize a registration mechanism when a client comes online. The idea is that the client send an UDP with its own IP Address to the host, and the host in return opens the connection with the transmitted address instead of permanently trying to reconnect to a non-existing client(s). This should avoid the DNS lookupproblem for non existing client and its opening delays. At least this is the plan.

Jörn

[Ben]

---

@joernheit wrote:

Thanks a lot Rolf for the valuable insight. I do understand that semaphores are required sometimes. Up to now my perspective towards networking with labview was kind of toplevel : listen, open, read/write, close thats it !. Now I see the  necessity to increase the knowledge.

I tried your Network Library some weeks ago but ran into problems. Now I don't know why I didn't come back to you with a proper error description. Sorry for that, but you can count on me for beta testing if you are ready with the update. And of course your work is very much appreciated. There must be tons of manhours in the libraries, not only the networklib but also lua, etc.

@Mark: I don't mean simply replacing TCP with UDP functions, but to realize a registration mechanism when a client comes online. The idea is that the client send an UDP with its own IP Address to the host, and the host in return opens the connection with the transmitted address instead of permanently trying to reconnect to a non-existing client(s). This should avoid the DNS lookupproblem for non existing client and its opening delays. At least this is the plan.

Jörn

---

We have used that method with great success for many years in an app where we monitoring equipment at drilling sites and have to "discover" new equipment as it arrives on-site.

As I understand it, it is the same method used to discover printers on a local network where they broadcast the service and anyone that understands the message can connect.

Re:Rolf

If LV has a foundation then he is one of the bigger stones that went into its construction.

Ben

[Mark_Yedinak]

---

@Ben wrote:

---

@joernheit wrote:

Thanks a lot Rolf for the valuable insight. I do understand that semaphores are required sometimes. Up to now my perspective towards networking with labview was kind of toplevel : listen, open, read/write, close thats it !. Now I see the  necessity to increase the knowledge.

I tried your Network Library some weeks ago but ran into problems. Now I don't know why I didn't come back to you with a proper error description. Sorry for that, but you can count on me for beta testing if you are ready with the update. And of course your work is very much appreciated. There must be tons of manhours in the libraries, not only the networklib but also lua, etc.

@Mark: I don't mean simply replacing TCP with UDP functions, but to realize a registration mechanism when a client comes online. The idea is that the client send an UDP with its own IP Address to the host, and the host in return opens the connection with the transmitted address instead of permanently trying to reconnect to a non-existing client(s). This should avoid the DNS lookupproblem for non existing client and its opening delays. At least this is the plan.

Jörn

---

We have used that method with great success for many years in an app where we monitoring equipment at drilling sites and have to "discover" new equipment as it arrives on-site.

As I understand it, it is the same method used to discover printers on a local network where they broadcast the service and anyone that understands the message can connect.

Re:Rolf

If LV has a foundation then he is one of the bigger stones that went into its construction.

Ben

---

Please be aware that UDP discoveries may not always work. If you are discovering devices on your local subnet you should generally be OK. If however you are crossing subnets you may run into trouble. Many network infrastructures are configured to restrict UDP broadcast packets to local subnets only. This is done to avoid doing world wide UDP discoveries.

Another thing you might want to consider would be to do your single name lookup in the beginning and then create a background task to simply ping the device on regular intervals to make sure it is still there. If the pings fail for some specified number of times you can try another name lookup. This would generally only be required if you will be communicating intermittently with the device. If you are communicating frequently you can do the name lookup as an error recovery to when the open fails.