*:Choosing a specific interface for Condor use in multi-homed IPv6 host. Use param "NETWORK_INTERFACE".
-{section: Note for constants}
{section: Converting utility functions}
{subsection: struct hostent}
@@ -76,27 +75,6 @@
}
{endcode}
-{subsection: get_full_hostname *RESOLVED}
-
-my_ip_addr, my_hostname, my_full_hostname() and get_full_hostname() are now obsolete. Now, implementing ipv6_hostname.{h/cpp}.
-
-It uses gethostbyname() which has been obsoleted. It should call getaddrinfo() instead. The function has about 150-200 lines of code. At the end of function, it tail-calls get_full_hostname_from_hostent(). struct hostent is also deprecated structure.
-
-It requires overhaul from interface to implementation.
-
-Importance: ?
-
-** I reimplemented get_full_hostname* and my_hostname*. Newer implementation exists at ipv6_hostname.*
-
-{subsection: IpVerify}
-
-[zach] implemented by mostly Todd, and little bit by Zach and Dan.
-
-IpVerify verifies the remote process's ip from the configuration file. IpVerify heavily uses in_addr structure internally. I would simply change it to in6_addr and map IPv4 address into IPv6. (so called V4MAPPED). It would make Condor slightly slower and use more memory. However, having two different code path for IPv4 and IPv6 does not seem nice. 4byte->16byte would not be much overhead and will make everything cleaner and easier. Also, I guess future IP address system will surely be super-set of current IPv6 as IPv6 is super-set of IPv4.
-
-V4MAPPED address works fine. One caveat is that the log will have IPv6-formatted IP address, e.g. ::ffff:127.0.0.1. If somebody do mind, it is possible to remove "::ffff".
-
-
{section: Converting Sock}
Sock is not only used by TCP/UDP connection but also used by Unix domain socket (AF_UNIX). Basically, Sock can only create TCP or UDP socket internally but SharedEndPoint and SharedPortClient creates Unix domain socket and calls Sock::assign() to pass the descriptor.
@@ -176,8 +154,24 @@
It is quite common practice in Condor source code that returning a pointer of a static buffer in a function. It was perfectly fine in a world that pthread is rare and multi-core is unknown. It is obviously non-re-entrant and non-thread-safe. Well, I could do as it was. But, I am slightly uncomfortable of writing such a function. So, I decided to use MyString instead of returning a pointer of a static buffer.
-{subsection: changes}
+{subsection: get_full_hostname *RESOLVED}
+
+my_ip_addr, my_hostname, my_full_hostname() and get_full_hostname() are now obsolete. Now, implementing ipv6_hostname.{h/cpp}.
+
+It uses gethostbyname() which has been obsoleted. It should call getaddrinfo() instead. The function has about 150-200 lines of code. At the end of function, it tail-calls get_full_hostname_from_hostent(). struct hostent is also deprecated structure.
+
+It requires overhaul from interface to implementation.
+
+** I reimplemented get_full_hostname* and my_hostname*. Newer implementation exists at ipv6_hostname.*
+
+{subsection: IpVerify}
+
+[zach] implemented by mostly Todd, and little bit by Zach and Dan.
+
+IpVerify verifies the remote process's ip from the configuration file. IpVerify heavily uses in_addr structure internally. I would simply change it to in6_addr and map IPv4 address into IPv6. (so called V4MAPPED). It would make Condor slightly slower and use more memory. However, having two different code path for IPv4 and IPv6 does not seem nice. 4byte->16byte would not be much overhead and will make everything cleaner and easier. Also, I guess future IP address system will surely be super-set of current IPv6 as IPv6 is super-set of IPv4.
+
+V4MAPPED address works fine. One caveat is that the log will have IPv6-formatted IP address, e.g. ::ffff:127.0.0.1. If somebody do mind, it is possible to remove "::ffff".
-should i change?
+{subsection: Interface Changes - should I do?}
Sock::get_port() -> Sock::my_addr().get_port() *for consistency. <- Well, I guess it should be in the future but not now.
