search

nasa / to_lab

The Core Flight System (cFS) Telemetry Output Lab App (to_lab)
Apache License 2.0
26 stars 41 forks source link

Use alternate/non-overlapping UDP ports for multiple CPUs #200

Open jphickey opened 4 months ago

jphickey commented 4 months ago

Is your feature request related to a problem? Please describe. Currently, TO_LAB always sends telemetry to the port number indicated in the interface config. Specifically, this is TO_LAB_TLM_PORT and it is defined as 1235 by default.

This means, when running TO_LAB on both cpu1 and cpu2 of a two-cpu deployment, they will both send to port 1235 on the receiver. In some configurations this is a problem, if the user wishes to have to separate instances of their ground system.

Notably --- this is different than what CI_LAB does. CI_LAB adds its CPU number to the base port, such that each instance is distinct and does not conflict.

Describe the solution you'd like In the short term, as a quick fix -- simply add the CPU number such that it works just like CI_LAB does. This will at least allow traffic to be separated at the transport layer.

Describe alternatives you've considered In the longer term, it might be worth adding another command to be able to configure the port number.

Additional context Needed by DTN, which is looking to run two instances of the ground system I/F and thus needs two different UDP ports.

Requester Info Joseph Hickey, Vantage Systems, Inc.

jphickey commented 4 months ago

Pinging @keegan-moore for awareness

keegan-moore commented 4 months ago

Pinging @keegan-moore for awareness

Thanks. For clarification, DTN doesn't plan to have two instances of the ground system. We intend to connect one ground system to talk to multiple cFS instances. We'd just like to be able to send the telemetry to two different ports (handled by the same ground system). This is a minor clarification and doesn't really change the intent or suggested solution.

skliper commented 4 months ago

Why not just have a unique to_lab_interface_cfg.h for each target? No code changes... just prefix the config w/ the target name so the build system picks the right one. If you've got different CPU numbers that means different images for each already, right?

jphickey commented 4 months ago

@skliper -- in the DTN build (and as I suggest most builds should do) we are loading the exact same binary .so files on both targets. They are identical. In other words, we aren't rebuilding to_lab specifically for each. The only difference is the table files we load.

In general I'd suggest we continue moving away from the assumption that there will be a separate/different binary file for each target.

The preferred solution would be to make this part of the TO_LAB configuration table and/or add a command to make it configurable at runtime, similar to the way "dest_IP" is specified.

jphickey commented 4 months ago

If you've got different CPU numbers that means different images for each already, right?

Nope!! This is not what we are doing. The same binaries go on both targets.

skliper commented 4 months ago

Got it! I vote for the config table then, unless there's a true requirement for run time configurability (which doesn't sound like it in this case).