-
Notifications
You must be signed in to change notification settings - Fork 174
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
eCAL TCP Layer, attempt to resolve .local instead of just hostname [Link-local connection] #1531
Open
1 of 3 tasks
Labels
enhancement
New feature or request
Comments
I started taking a look at this and implemented a first draft for eCAL Services. I didn't want to implicitely append '.local' from within the service lib, so I created an API that would not only get 1 possible endpoint but a list of them. If the first one wouldn't respond, the next one would be tried. Unfortunately I cannot really test this at the moment due to technical reasons. The current status can be compiled as follows:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I understand that in the current TCP mode, in order to use eCAL properly, we have to manually key in the hostname-IP mapping on the subscriber machine. This is pretty inconvenient for deployment to customers' machine.
I have tested on both Windows and Ubuntu Linux hosts. There is a good workaround potentially to make the TCP mode work without config.
The trick is that, althought hostnames are not resolved direclty, espically when there is not present of a router (e.g. direct ethernet cable connect of the host and edge machine), by adding the ".local" domain, the mDNS mechanism kicks and systems are able to resolve the hostname.
My suggestion is then:
Originally posted by @chengguizi in #1521
Roadmap
The text was updated successfully, but these errors were encountered: