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

Remote hostname resolved only once #29

Closed
nbaztec opened this issue Sep 6, 2018 · 2 comments · Fixed by #30
Closed

Remote hostname resolved only once #29

nbaztec opened this issue Sep 6, 2018 · 2 comments · Fixed by #30

Comments

@nbaztec
Copy link
Contributor

nbaztec commented Sep 6, 2018

Step 1: Describe your environment

  • Ubuntu 18.04
  • .NET core 2.1.401

Step 2: Describe the problem

Currently the UDP Sink supports a hostname as a destination in the configuration. Due to the implementation however the hostname is resolved only once at the application startup. This effectively removes the advantages associated with using hostnames since any future changes to the DNS won't be adjusted by the application at all.

Steps to reproduce:

  1. Setup a local hostname foobar.local via /etc/hosts/. Point it to a locally available UDP listener (service, etc.). For example, running on 192.168.1.100.
  2. Start a test application with the UDP sink and the value remoteAddress = foobar.local in the configuration. Keep it running so it's sending contant packets to the UDP listener service.
  3. Verify that the packets are being received.
  4. Terminate the UDP listener and move it to a different host. For example to 192.168.1.200.
  5. Adjust the /etc/hosts to point foobar.local to the new IP 192.168.1.200.
  6. The running test application would no longer adapt to the moved UDP listening service and would still be sending to the old IP since it does not use the hostname beyond the setup stage.

Observed results

  • Since the IP resolution was done at startup time, the hostname is meaningless in the logging context.

Expected results

  • The UDP packets should've been sent to the hostname, irrespective of the IP change without restarting the Logging application.
@FantasticFiasco
Copy link
Owner

I think you are correct. I will look at the PR tonight, lets get this embarresing issue solved as soon as possible.

Thanks for reporting the issue!

@nbaztec
Copy link
Contributor Author

nbaztec commented Sep 6, 2018

No worries, glad to help :)

FantasticFiasco pushed a commit to nbaztec/serilog-sinks-udp that referenced this issue Sep 9, 2018
Fixes issue where the hostname only resolves into an IP address when the
sink is created. The very nature of hostnames is to provide a route to
instances whose IP address may change, and these code changes allows for
this situation.

One limitation with the changes is that currently only IPv4 addresses are
supported, but an upcoming PR will solve that issue.

Closes FantasticFiasco#29
FantasticFiasco pushed a commit that referenced this issue Sep 9, 2018
Fixes issue where the hostname only resolves into an IP address when the
sink is created. The very nature of hostnames is to provide a route to
instances whose IP address may change, and these code changes allows for
this situation.

One limitation with the changes is that currently only IPv4 addresses are
supported, but an upcoming PR will solve that issue.

Closes #29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants