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

resolve names when showing session #86

Merged
merged 1 commit into from Apr 17, 2014

Conversation

Projects
None yet
2 participants
@tadokoro
Contributor

tadokoro commented Mar 20, 2014

This is a patch which resolves names when jool shows the sessions.
I want to know names for easy to understand a situation.
Its default is resolving host. It may be controversial but I followed the behavior of netstat, for example.

@ydahhrk ydahhrk added this to the 3.1.4 milestone Mar 26, 2014

@ydahhrk ydahhrk self-assigned this Mar 26, 2014

@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Apr 2, 2014

Member

Ok, cool.

I'm planning to code a couple of modifications. I propose the following; would you mind sharing your opinion?

  • If the query fails, the client should fall back to print the ugly numerical address instead of the error message ("getnameinfo failed: %s"). This way you wouldn't leave the user completely helpless.
  • It seems to me that this behaviour should be mirrored in the BIB tables. Did you have any special reasons to not implement that?

Thank you.

Aaaaand sorry for taking so long to review the code -.-

Member

ydahhrk commented Apr 2, 2014

Ok, cool.

I'm planning to code a couple of modifications. I propose the following; would you mind sharing your opinion?

  • If the query fails, the client should fall back to print the ugly numerical address instead of the error message ("getnameinfo failed: %s"). This way you wouldn't leave the user completely helpless.
  • It seems to me that this behaviour should be mirrored in the BIB tables. Did you have any special reasons to not implement that?

Thank you.

Aaaaand sorry for taking so long to review the code -.-

@tadokoro

This comment has been minimized.

Show comment
Hide comment
@tadokoro

tadokoro Apr 3, 2014

Contributor

I'm glad to your response.

  • Yes, I also think falling back is better.
  • No, I did not just notice it. I also think it also should be implemented in the BIB tables.

thank you.

Contributor

tadokoro commented Apr 3, 2014

I'm glad to your response.

  • Yes, I also think falling back is better.
  • No, I did not just notice it. I also think it also should be implemented in the BIB tables.

thank you.

@ydahhrk ydahhrk merged commit 14f2c40 into NICMx:master Apr 17, 2014

@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Apr 25, 2014

Member

Actually, I'm scratching my head trying to document this.
I understand why resolving the remote addresses is meaningful, but is there a good reason to do the same with the local ones?
The local IPv4 addresses are always going to be part of the NAT64 pool, which means they all usually resolve to the same name.
The local IPv6 address is a prefixed version of the remote IPv4 address, which means that if the DNS64 works properly, both addresses should resolve to the same name.

Do you really need the resolution for local addresses?

Member

ydahhrk commented Apr 25, 2014

Actually, I'm scratching my head trying to document this.
I understand why resolving the remote addresses is meaningful, but is there a good reason to do the same with the local ones?
The local IPv4 addresses are always going to be part of the NAT64 pool, which means they all usually resolve to the same name.
The local IPv6 address is a prefixed version of the remote IPv4 address, which means that if the DNS64 works properly, both addresses should resolve to the same name.

Do you really need the resolution for local addresses?

@tadokoro

This comment has been minimized.

Show comment
Hide comment
@tadokoro

tadokoro Apr 27, 2014

Contributor

You are right.
Resolving the local addresses is almost always meaningless.
I don't need it. (^^)/

Contributor

tadokoro commented Apr 27, 2014

You are right.
Resolving the local addresses is almost always meaningless.
I don't need it. (^^)/

ydahhrk added a commit that referenced this pull request Apr 28, 2014

Ready to release.
- The site now suports SSL, so the links now reflect that.
- Added the google analytics code to the website.
- Added some sample output to the userspace application's doc HTML.
- Removed some unneded DNS queries. See issue #86.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment