{section: IPv6 Mode}
-Phase 3 is gonna have IPv6 mode. IPv6 mode basically makes Condor to prefer IPv6 address.
+Phase 3 is gonna have IPv6 mode. IPv6 mode basically makes HTCondor to prefer IPv6 address.
-With IPv6 mode turned on, Condor will create every socket as IPv6. (AF_INET6)
+With IPv6 mode turned on, HTCondor will create every socket as IPv6. (AF_INET6)
-However, it is still possible to interact with IPv4 Condor and also is possible to bind to IPv4 address!
+However, it is still possible to interact with IPv4 HTCondor and also is possible to bind to IPv4 address!
If the config allows to use any network interface, it uses the interface with IPv4 address to connect IPv4 host. It uses the interface with IPv6 address to connect IPv6 host, too!
@@ -57,9 +57,9 @@
One of the interesting thing about the link-local address is that the address contains the interface name. For example, fe80::862b:2bff:fe98:65f2%eth0. The interface name is required because given address is only valid in that interface.
-In Condor IPv6 testing, I'd like to use link-local IPv6 address. However, one caveat is that the interface name is different from system to system. Thus, we cannot use the link-local address with the interface name as identifying machines.
+In HTCondor IPv6 testing, I'd like to use link-local IPv6 address. However, one caveat is that the interface name is different from system to system. Thus, we cannot use the link-local address with the interface name as identifying machines.
-Instead, what I am gonna do is that each Condor system who wants to use the link-local address has to specify the network interface of use. In condor_config, NETWORK_INTERFACE is required.
+Instead, what I am gonna do is that each HTCondor system who wants to use the link-local address has to specify the network interface of use. In condor_config, NETWORK_INTERFACE is required.
Each link-local address (which can be identifiable by looking at the address) will be bound to pre-configured NETWORK INTERFACE.
@@ -78,7 +78,7 @@
{section: network_adapter.* and IPv6}
-Current method of getting network adapter is totally incompatible with IPv6 address. Current Condor uses ioctl() with SIOCGIFCONF that only returns IPv4 addresses.
+Current method of getting network adapter is totally incompatible with IPv6 address. Current HTCondor uses ioctl() with SIOCGIFCONF that only returns IPv4 addresses.
getifaddrs() is introduced to solve these problems. One caveat of getifaddrs() is that it does not tell you about the network interface id.
@@ -114,7 +114,7 @@
1) NO_DNS are transparently implemented over existing DNS functions. (gethostbyaddr -> condor_gethostbyaddr, ...)
2) These functions and structures are currently obsolete. The interfaces and the structures are limited to IPv4 or is not protocol independent. (Current IPv6 socket functions are all protocol independent - they can work on any layer 2 protocol)
3) If caller uses obsolete structure, it usually intertwined with caller's loop as well. (DNS structure usually contains linked list)
-4) Condor offer same function in many different forms. (condor_gethostname+get_full_hostname, my_hostname, my_full_hostname are essentially same) Even with abundant of implementation, caller still needs to do housekeeping work by themselves.
+4) HTCondor offer same function in many different forms. (condor_gethostname+get_full_hostname, my_hostname, my_full_hostname are essentially same) Even with abundant of implementation, caller still needs to do housekeeping work by themselves.
I carefully looked at each case and extracted common use cases. These are
@@ -179,7 +179,7 @@
Don't forget below lists.
-*:Choosing a specific interface for Condor use in multi-homed IPv6 host. Use param "NETWORK_INTERFACE".
+*:Choosing a specific interface for HTCondor use in multi-homed IPv6 host. Use param "NETWORK_INTERFACE".
-- All done
@@ -222,7 +222,7 @@
-- do not need to think about this
-{section: List of Condor IP addr functions}
+{section: List of HTCondor IP addr functions}
-- All done here.
@@ -260,11 +260,11 @@
{endcode}
-{subsection: Condor NetDB}
+{subsection: HTCondor NetDB}
-Condor defines its own netdb-related functions (proxy functions) for its own DNS system called NO_DNS.
+HTCondor defines its own netdb-related functions (proxy functions) for its own DNS system called NO_DNS.
--- all done. reimplemented condor netdb
+-- all done. reimplemented HTCondor netdb
{section: What is it?}
TCP_FORWARDING_HOST : it seems it used by startd. when the job (startd) tries to connect shadow and TCP_FORWARDING_HOST is defined, it connects to TCP_FORWARDING_HOST. It seems like some kind of NAT or proxy.
@@ -296,7 +296,7 @@
{subsection: Returning a pointer of a static buffer inside a function}
-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.
+It is quite common practice in HTCondor 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: get_full_hostname *RESOLVED}
@@ -312,7 +312,7 @@
[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.
+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 HTCondor 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".
