I’m thinking of using multicast UDP in a certain piece of software I’m working on. I have read the FMS whitepaper and searched the Web (and these forums), and I still could not find any specific information about what ports/IPs/etc. are allowed by the FMS.
Here is what I know:
From the FMS whitepaper:
The ports that the teams are able to access on the competition field are as follows:
UDP/TCP 1180 - 1190: This port range is typically used for camera data from the Robot to the DS when the camera is connected to the roboRIO via USB. This port is bidirectional on the field.
TCP 1735: SmartDashboard, bidirectional
UDP 1130: Dashboard-to-Robot control data, directional
UDP 1140: Robot-to-Dashboard status data, directional
HTTP 80: Camera connected via switch on the robot, bidirectional
HTTP 443: Camera connected via switch on the robot, bidirectional
UDP/TCP 554: Real-Time Streaming Protocol for h.264 camera streaming, bi-directional
UDP/TCP 5800-5810: Team Use, bi-directional
This list of ports does not mention mDNS, which broadcasts to 224.0.0.251 port 5353. The FMS documentation does mention that mDNS is a part of the control system, and I have seen posts on these forums that mDNS does work in the field. In my experience though, mDNS is rather unreliable, so I’m not going to risk using it…
So the question is: What are the restrictions, if any, in the FMS’s firewall with regards to multicast UDP?
The FMS whitepaper is vastly out of date, your best option would be to ask an FTA or CSA for more information on this.
From looking at the Offseason FMS, there probably isn’t any restrictions on multicast at all, but there may be in the AP side of things.
That specific part of the whitepaper is still fairly relevant (there may be some additional open ports other than the ones specified, although whether 5353 is open for “team use” is debatable). Also, that list of ports matches table 3-2 in this year’s manual.
My team experimented briefly with multicast UDP in 2016 (off the field) and found that ports in the 5800-5810 range worked, while a few others (not listed at all) didn’t work. I would recommend sticking with the listed ports. Other than that, I haven’t dealt with it on the field before, but you might need to set your packets’ TTL to >= 2 if 1 doesn’t work.
2 years ago we tried multicasting video, and that absolutely killed our ability to communicate. Like Jaci says, it’s used for mDNS so you could use it for avahi/bonjour type service discovery, but it’s probably a bad idea for high bandwidth applications
R65. Communication between the ROBOT and the OPERATOR CONSOLE is restricted as follows:
A. Network Ports: UDP/TCP 1180-1190: Camera data from the roboRIO to the Driver Station (DS) when the camera is connected the roboRIO via USB, bi-directional. TCP 1735: SmartDashboard, bi-directional UDP 1130: Dashboard-to-ROBOT control data, uni-directional UDP 1140: ROBOT-to-Dashboard status data, uni-directional HTTP 80: Camera connected via switch on the ROBOT, bi-directional HTTP 443: Camera connected via switch on the ROBOT, bi-directional UDP/TCP 554: Real-Time Streaming Protocol for h.264 camera streaming, bi-directional UDP/TCP 5800-5810: Team Use, bi-directional
Teams may use these ports as they wish if they do not employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the ROBOT and the DS if the Team chooses not to use the camera on USB).
B. Bandwidth: no more than 7 Mbits/second.
As stated in the original post, the team handbook and white paper make no mention of mDNS or multicast. That’s why I’m asking whether there are any limitations on the port or IP for multicasting.
Multicast requires a broadcast domain. The FRC field network SEEMS to be broken into at least 7 different broadcast domains with at least some overlap for the driver stations.
If you can be more specific about what you are planning to do then it might help with explaining if it is possible.
My suggestion is that if you are trying to rely on this system for competition then banking on multicast to work is not a good idea and you’ll likely end up with something that works at one venue and one year but not others. My usual disclaimer for these things is: treat the field network like a black box.
As has been implied earlier, you should be sure you keep your multicast traffic down to a bare minimum unless you know how all of the gear involved is going to react to multicast (which is not possible with respect to the field network).