Strange mDNS behavior

[Greg McKaskle]

The m in mDNS stands for multi-cast, and from logs, there are times when the Windows multi-cast services seems to be using cached results and the DS is not able to resolve -- until something causes the multi-cast stuff to rebuild its tables, and then everything works again.

I have not seen this at all this year on our test system or on the robots, but I saw it occasionally last year. Other mDNS implementation gotchas were fixed, but this one didn't have an obvious workaround that we wanted to incorporate into the DS. Bringing an interface up or down seems like the sort of thing that might poke the multi-cast to rebuild. Disconnecting and reconnecting an ethernet cable would often do it when that was the interface to the robot.

I understand that static IPs are a solution of sorts, but they introduce other issues, especially when that robot shows up at an event. The robot won't connect to the field, so the CSA or FTA discovers and changes the roboRIO and DS laptop settings. But that may break the programming laptop connectivity, so the team may change it back again, ...

So if you go the static route, please report the issues that caused you to go static. Don't go static just because the cool kids are doing it. And please set your stuff back to use DHCP when you go to an event.

Thanks from a guy wearing an orange hat.
Greg McKaskle