bodacious

QUOTE (jdunham @ Oct 30 2008, 05:39 PM) 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!

QUOTE (Dan DeFriese @ Oct 29 2008, 11:43 AM) 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.

QUOTE (Dan DeFriese @ Oct 29 2008, 10:20 AM) 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.

QUOTE (Dan DeFriese @ Oct 29 2008, 09:45 AM) 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?

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?