Remove INET_ADDRSTRLEN limit for symbolic hostnames and optimize socket connections.#578
Merged
edwardalee merged 10 commits intomainfrom Apr 15, 2026
Merged
Remove INET_ADDRSTRLEN limit for symbolic hostnames and optimize socket connections.#578edwardalee merged 10 commits intomainfrom
INET_ADDRSTRLEN limit for symbolic hostnames and optimize socket connections.#578edwardalee merged 10 commits intomainfrom
Conversation
… resolution if the IP address (`struct in_addr`) is already provided.
INET_ADDRSTRLEN limit for symbolic hostnames and optimize socket connections.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the socket-based network abstraction used by the federated runtime to (1) avoid truncating symbolic hostnames, and (2) optimize certain federate-to-federate connections by using an already-available IPv4 address directly instead of round-tripping through presentation format + DNS resolution.
Changes:
- Removed persisted
server_hostnamestorage fromsocket_priv_t(fixes hostname truncation caused byINET_ADDRSTRLEN-sized buffers). - Extended socket connection parameters to optionally pass a raw
struct in_addr*and bypassgetaddrinfo()when available. - Cleaned up ineffective “set local pointer to NULL after shutdown” code paths.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
network/impl/src/socket_common.c |
Removes debug hostname storage; adds connect_to_socket() fast-path using struct in_addr. |
network/impl/src/lf_socket_support.c |
Stops copying hostname into a fixed-size buffer; passes hostname/IP through to connect_to_socket(). |
network/api/socket_common.h |
Adds optional server_ip_addr to connection params; removes server_hostname from socket_priv_t; updates API docs/signature. |
core/federated/RTI/rti_remote.h |
Updates comments to reflect removal of server_hostname tracking. |
core/federated/RTI/rti_remote.c |
Removes hostname-based debug log and ineffective NULL assignments after shutdown. |
core/federated/federate.c |
Uses server_ip_addr when connecting to federates; avoids terminating accept loop on transient accept failure. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
edwardalee
approved these changes
Apr 15, 2026
Contributor
edwardalee
left a comment
There was a problem hiding this comment.
LGTM! I tested and am able to start a multi-machine federation now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
server_hostnamefromsocket_priv_t, which was actually not necessary to save in the struct.net_absin stack to NULL aftershutdown_net().connect_to_socket()usein_addrinstead ofchar* hostnamewhen available.1. Remove
server_hostnamefromsocket_priv_tThere was a bug found in #576, which happened after merging #508, not allowing symbolic hostnames longer than 16 bytes (
INET_ADDRSTRLEN) from being connected.This happened because there was a
memcpy()to save the host_name inchar server_hostname[INET_ADDRSTRLEN];.While investigating this, the code only used this for printing debug messages on the hostname, and it was never used again.
I removed the
server_hostnamefield fromsocket_priv_t.2. Bug Fix: Remove unnecessary NULL setting to pointers.
After
shutdown_net(net_abs), I set allnet_absto NULL, however some were just pointers from the stack, so had no effect. Removed all of these. Thanks for reporting this @edwardalee.3. Support
connect_to_socket()usein_addrinstead ofchar* hostnamewhen available.When a federate tries to connect another federate, the RTI sends the target federate's IP address in a network format (
uint32_t), not the presentation format (192.168.0.1orlocalhost).However,
connect_to_socket()only supported the presentation format as the input parameter.So there was some inefficiency where
federate.cdoesinet_ntop()to convert the recieved network format into the presentation format, and insideconnect_to_socket, doesgetaddrinfoto convert that presentation format backward into the network format (struct sockaddr_in) to make the actual system callconnect().So, by updating
connect_to_socket()to accept an optionalstruct in_addr*, this PR removes this redundant Network -> Presentation -> Network conversion, which removes unnecessary DNS resolution overhead.Why we couldn't remove
getaddrinfo()entirely?The redundancy above was from
lf_connect_to_federate, however,connect_to_netis used once again inlf_connect_to_rti.However, when used in
lf_connect_to_rti, this always uses thechar* hostname, because the RTI's address is provided strictly as a human-readable string (e.g., "localhost", "192.168.0.1" or "rti-server.domain.com"), performing DNS resolution viagetaddrinfo()is mandatory to discover its actual network routing address. Therefore,connect_to_socket()was updated to selectively bypass DNS only when a raw IP is available.This suggestion was also made by @edwardalee, thanks for your insight!