Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jphickey opened this issue Jul 24, 2024 · 6 comments
Open

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

jphickey opened this issue Jul 24, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@jphickey
Copy link
Contributor

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
Copy link
Contributor Author

Pinging @keegan-moore for awareness

@keegan-moore
Copy link

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
Copy link
Contributor

skliper commented Jul 24, 2024

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link
Contributor

skliper commented Jul 25, 2024

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).

@dzbaker dzbaker added the enhancement New feature or request label Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants