Consider populating the "name" field of datagram socket entries #1224
Labels
Comments
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
This also fixes up/simplifies some include directives in UT headers Additionally this updates UT_ResetState() in ut_support to always configure the AppId for CFE_ES_GetAppId. Unfortunately some TBL test cases require/assume the "real" app IDs. This works around the issue and allows TBL tests to pass. (This is really a weakness/fragility in TBL tests).
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Fix nasa#1224, reinstate recipes for coverage test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
As noticed in previous issue #1222, the datagram sockets are essentially name-less. This means that the
name_entryfield of these entries is left unset, and will be NULL.This is different than most other OSAL resource types, which all have names.
Describe the solution you'd like
Stream sockets (IIRC) generate a name consisting of the local IP address/port and remote IP address/port. Datagram sockets are connectionless, but theoretically this field could still be populated with something unique, such that name-based APIs could work.
Describe alternatives you've considered
Leave as-is, where datagram sockets remain anonymous/nameless.
Additional context
Most name-based OSAL APIs (such as OS_CloseFileByName) intentionally only operate on files - they check if the entry is a socket and ignore it if it is, so having a name associated with sockets if of limited usefulness unless we open that up, which also may not be a bad idea. (i.e. one can get the name by calling OS_FDGetInfo, then pass that name to OS_CloseFileByName or OS_FileOpenCheck, etc).
Requester Info
Joseph Hickey, Vantage Systems, Inc.
Based on CCB discussion of #1223 on 2022-02-23
The text was updated successfully, but these errors were encountered: