You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
This bug is to track the cleanup of the IP parsing logic. Currently it is spread across s/c/n/utility.cc and s/c/n/address_impl.cc
Another thing to notice is that if we simply move the parsing logic from utility to address_impl we have the following circular dependency:
It would also be nice to leverage a single parsing method like the getaddrinfo instead of the combination of that plus the inet_pton. The problem in doing that though is that apparently at the moment the windows version of the getaddrinfo has a different behavior than other platforms so we need to figure if this can be cleaned up for every platform or we need some special logic for windows.
@yanavlasov mentioned:
As an aside the makeFriendlyName needs to be optimized (it is worth a few percentage points of CPU for configs with large number of EDS endpoints) and not even call inet_ntop for endpoint addresses that are already IP address strings and can just simply be copied into the friendly name. This will take care of resolving the interface name as well for the most part.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
Title: Cleanup IP parsing logic
Description:
This bug is to track the cleanup of the IP parsing logic. Currently it is spread across s/c/n/utility.cc and s/c/n/address_impl.cc
Another thing to notice is that if we simply move the parsing logic from utility to address_impl we have the following circular dependency:
It would also be nice to leverage a single parsing method like the
getaddrinfo
instead of the combination of that plus theinet_pton
. The problem in doing that though is that apparently at the moment the windows version of thegetaddrinfo
has a different behavior than other platforms so we need to figure if this can be cleaned up for every platform or we need some special logic for windows.@yanavlasov mentioned:
As an aside the
makeFriendlyName
needs to be optimized (it is worth a few percentage points of CPU for configs with large number of EDS endpoints) and not even callinet_ntop
for endpoint addresses that are already IP address strings and can just simply be copied into the friendly name. This will take care of resolving the interface name as well for the most part.The text was updated successfully, but these errors were encountered: