It looks like you have the latest. The multicast socket is not always ignored during the read operation. However, the unicast socket does always take priority over the multicast socket. My guess is that in your case the unicast packets may be coming in so fast that the system never has time to catch up and empty the unicast socket's buffer, which then allows it to read in the multicast packets. This may take some code rework to fix, because the linux multicast implementation differs slightly from the windows implementation, and when we wrote this we had quite a struggle to find a cross platform solution.

However, we might also be able to fix this with some configuration changes (slow down some messages, speed up others or change timeout values). Can you give us some idea of what time of messages are being sent, and how fast? I'm assuming that the problem is that the receiving node manager is failing to process the multicast packets. Can you verify that is correct?

Have you tried running the just the node manager and none of your components? There is no way that configuration should generate enough unicast traffic to swamp a connection. If you can do that and get reliable and stable performance out of the System Tree (i.e. your OCU does not time out) then it is worthwhile to look at what unicast traffic is flowing and why that would saturate the connection.

Also I would recommend running Wireshark on the OpenJAUS-based node and seeing if you see the multicast packet arriving on the OJ Subsystem. Also, this is subsystem to subsystem correct? You may want to double check the settings in the nodemanager.conf file and just make sure they are valid.

It is most likely a configuration error somewhere in the system. We have used OpenJAUS in some very strenuous environments and not swamped out that code before. Running ojNodeManager by itself without components attached will help a lot because it will eliminate 90% of the unicast traffic. A wireshark log will help as well as we can analyze it to see what messages are flowing as well as their content to see if something is configured improperly.

Sorry guys, but I was misinterpreting my debugging output. That whole notion of "swamping the socket" with unicast messages turns out to be a red herring.

It turns out that the multicastSocket is indeed attempting to read from its multicast descriptor quite often. It's just that the call to "select" times out after a second, as if there is simply no data available on the multicast address's port.

I have often thought that I have missed something obvious in the nodeManager.conf file, but I never find anything that jumps out at me. Because I understand very little about what constitutes a valid set of settings, I have been hesitant to change anything unless I'm pretty sure. Even when I got a little more adventurous, things went from bad to worse. (Besides, I took the fact that outgoing multicasts were working to indicate that all was well from a configuration standpoint.)

But, I have attached my copy of the nodeManager.conf file -- you might find what I have overlooked in about two seconds. (The [Node Communications] section is calling out for something, but none of my attempts to provide it helped.)

Your .conf file looks ok. You should probably set the node communications enabled to false, if you're not going to enable any interfaces on it. However, it shouldn't cause any problems.

To help you figure this out further we probably need to see a diagram of how you have your nodes hooked up, and definitely some wireshark logs that show exactly what the OCS is sending to the node manager. My guess is that the multicast addresses do not agree. This may be something we can add to your config file to fix it.

To give you as much context as possible, I'll tell you this... The hardware and software environment of my OpenJaus-based subsystem is one that Danny is very familiar with (much more so than I), the Go-C camera platform running his code on a Gumstix processor.

Danny, have you ever seen the Go-C module receive external multicast heartbeats? At this point, I'm finding it difficult to blame OpenJaus or the Go-C module, so the configuration settings are most suspect.

Yes, of course the Gumstix and the software you are using is capable of receiving multicast heartbeats. It has been used extensively with a windows based console program built around the XBox360 controller and running OpenJAUS.

Again, the easiest path to a solution for you is to run Wireshark on your OCU machine and create a log of the UDP traffic. This will easily show if the multicast address is misconfigured, which seems the most likely problem at this point. I would also encourage you to create a log on the gumstix subsystem as well. You can use libpcap to create a log which can be imported into Wireshark.