TCP Network Broadcast in LV

[bodacious]

I'm looking for a way to broadcast information in a local network, say 192.168.1.xxx.

If I broadcast to 192.168.1.255, LabView returns error 54 "The network address is ill-formed". I assume that error occurs in the software and is not necessarily hardware limited. Has anybody experienced something similar and has come up with a work-around?

If not, what's the best way to establish a list of known and responsive nodes in a network through LV?

[Dan DeFriese]

QUOTE (bodacious @ Oct 29 2008, 10:51 AM)

I'm looking for a way to broadcast information in a local network, say 192.168.1.xxx.

If I broadcast to 192.168.1.255, LabView returns error 54 "The network address is ill-formed". I assume that error occurs in the software and is not necessarily hardware limited. Has anybody experienced something similar and has come up with a work-around?

If not, what's the best way to establish a list of known and responsive nodes in a network through LV?

I don't believe you can "broadcast" using the TCP primitives as this would violate Transfer Control Protocol. Broadcasting with the UDP primitive is simple just set the send to IP to 255.255.255.255 or 0xFFFFFFFF as shown in the screenshot. However, broadcasting in this way sends the UDP datagram from all network interfaces on the machine (at least in Windows). You can use UDP Multicast to limit this to a specific subnet.

What do mean by responsive nodes? Can you describe your app a litte more?

[bodacious]

QUOTE (Dan DeFriese @ Oct 29 2008, 09:45 AM)

I don't believe you can "broadcast" using the TCP primitives as this would violate Transfer Control Protocol. Broadcasting with the UDP primitive is simple just set the send to IP to 255.255.255.255 or 0xFFFFFFFF as shown in the screenshot. However, broadcasting in this way sends the UDP datagram from all network interfaces on the machine (at least in Windows). You can use UDP Multicast to limit this to a specific subnet.

What do mean by responsive nodes? Can you describe your app a litte more?

Thanks Dan,

I see your point, since TCP is a peer-to-peer protocol. The reason I don't want to go to UDP is the unpredictability (packets arriving and packets out of order).

So suppose I stay with TCP and suppose a network node comes up and wants to figure out what other network nodes are on the subnet. Can I do something like a ping to the whole subnet and get responses back or do I have to probe each IP seperately?

[Dan DeFriese]

QUOTE (bodacious @ Oct 29 2008, 12:00 PM)

So suppose I stay with TCP and suppose a network node comes up and wants to figure out what other network nodes are on the subnet. Can I do something like a ping to the whole subnet and get responses back or do I have to probe each IP seperately?

Is there a reason not to use a server app Fig A to host all the clients? Do all the nodes needs to know about each other Fig. B?

[bodacious]

QUOTE (Dan DeFriese @ Oct 29 2008, 10:20 AM)

Is there a reason not to use a server app Fig A to host all the clients? Do all the nodes needs to know about each other Fig. B?

Thanks Dan,

A server architecture would certainly solve a lot of problems, but I'm not 100% certain that all nodes will be able to see the server. In the final implementation we will employ a mesh radio to extend the wireless range, but I don't have the hardware yet, so I can't tell if that's an option or not. Another concern is data traffic volume - if we have a large number of nodes and all nodes need to exchange data will all nodes across the network the traffic scales with N^2, instead of just N if the nodes can broadcast their information.

[Dan DeFriese]

QUOTE (bodacious @ Oct 29 2008, 12:36 PM)

if we have a large number of nodes and all nodes need to exchange data will all nodes across the network the traffic scales with N^2, instead of just N if the nodes can broadcast their information.

Wouldn't broadcasting still result it N^2 traffic? Again, why should the every node communicate with each other (beyond not seeing the server directly)? Are the sharing data or reacting to each other's states?

Would it be possible for one of the clients to proxy for the remote client?

How about a periodic (every few seconds) UDP broadcast from each node to which all "visible" clients respond with a server connection status. If a client gets a response from a another client with a server connection status == FALSE it could provide proxy service.

[jdunham]

QUOTE (bodacious @ Oct 29 2008, 10:36 AM)

A server architecture would certainly solve a lot of problems, but I'm not 100% certain that all nodes will be able to see the server. In the final implementation we will employ a mesh radio to extend the wireless range, but I don't have the hardware yet, so I can't tell if that's an option or not. Another concern is data traffic volume - if we have a large number of nodes and all nodes need to exchange data will all nodes across the network the traffic scales with N^2, instead of just N if the nodes can broadcast their information.

At the risk of being a jerk, I will point out that you are designing a mesh network (whether or not you get mesh radios), and that mesh networks are hard, and a lot of people are doing PhDs and starting companies about them. If you are really going to reinvent all of this and since you have some pretty basic questions, I think you have a lot of struggle ahead. I don't want to say you couldn't do it, but I hope you are reading a lot of the literature, and looking for other forums where people have more relevant expertise (nothing personal intended to you or Dan).

[bodacious]

QUOTE (Dan DeFriese @ Oct 29 2008, 11:43 AM)

Wouldn't broadcasting still result it N^2 traffic? Again, why should the every node communicate with each other (beyond not seeing the server directly)? Are the sharing data or reacting to each other's states?

Would it be possible for one of the clients to proxy for the remote client?

How about a periodic (every few seconds) UDP broadcast from each node to which all "visible" clients respond with a server connection status. If a client gets a response from a another client with a server connection status == FALSE it could provide proxy service.

Dan - each node needs to receive data from every other node and vice versa send it's own data to every other node, so broadcasting would eliminate the need for node A to connect to each node in the network separately and just send one broadcast to the whole network. This would eliminate the need for connecting A-B, A-C, A-D, etc... I believe the mesh-radio will take care of proxying, so a server architecture might still work for out-of-sight nodes, so it's mostly a traffic volume thing.

jdunham - maybe I'm a bit too optimistic, but my understanding was that a COTS mesh-radio architecture will take care of dynamic routing and maintaining connectivity in the network, hence it should be transparent to me as a user that "only" deals with the individual nodes. Since I don't have the mesh-radio hardware on hand yet, I'm trying to emulate the network with a simple ethernet subnet, hence my questions about the TCP/UDP broadcasts.

[PaulL]

Perhaps you will want to take a look at the (object-oriented) Observer pattern.

There is an STM example that does pretty much the same thing.

Networked shared variables also do this--now with a TCP layer.

[jdunham]

QUOTE (bodacious @ Oct 29 2008, 01:14 PM)

jdunham - maybe I'm a bit too optimistic, but my understanding was that a COTS mesh-radio architecture will take care of dynamic routing and maintaining connectivity in the network, hence it should be transparent to me as a user that "only" deals with the individual nodes. Since I don't have the mesh-radio hardware on hand yet, I'm trying to emulate the network with a simple ethernet subnet, hence my questions about the TCP/UDP broadcasts.

Ok, that makes some sense. I presume you are ready for the fact that the mesh networking will consume a lot of the bandwidth of your radios, and you are accounting for that in your traffic analysis.

To answer more of your questions, more information about the design considerations is needed. If your network is reliable and you don't need a hard guarantee of delivery, then you should just use UDP for broadcasts. If those are not true, can you make one of the nodes a master node? Then you send all updates to it, and it can deliver the broadcasts in an efficient manner to each subscribed node. Is your network dynamic, that is will nodes connect and disconnect at unpredictable times?

[bodacious]

QUOTE (jdunham @ Oct 30 2008, 05:39 PM)

Ok, that makes some sense. I presume you are ready for the fact that the mesh networking will consume a lot of the bandwidth of your radios, and you are accounting for that in your traffic analysis.

To answer more of your questions, more information about the design considerations is needed. If your network is reliable and you don't need a hard guarantee of delivery, then you should just use UDP for broadcasts. If those are not true, can you make one of the nodes a master node? Then you send all updates to it, and it can deliver the broadcasts in an efficient manner to each subscribed node. Is your network dynamic, that is will nodes connect and disconnect at unpredictable times?

This application doesn't need that much data exchange (~<10kB/sec), however I want to keep the number of packets that are sent through the network small, because of the dynamic routing with the mesh radios. I think that N broadcasts in a mesh should be less traffic overall than NxN peer-to-peer broadcast, so I'm leaning more and more towards UDP. There are a couple of design reasons, why a server is not the preferred choice (dynamic network is the main one).

I think I will just start with UDP as a baseline and see later on what the performance in the mesh radio network is.

Thanks everyone who shared their opinion!