It looks very simple and obvious. But, there were 5-6 different implementations on each of them.
-{section: no modify sockaddr_in}
-*:amazon/ec2_sim_main.cpp - main() for testing
-*:c++_util/udp_waker.cpp - no broadcast for ipv6
+{section: unmodified sockaddr_in}
+*:amazon/ec2_sim_main.cpp - included in main() for testing
+*:c++_util/udp_waker.cpp - no broadcast for ipv6.
{section: finished sockaddr_in}
conversion of sockaddr_in were all finished.
@@ -131,9 +131,12 @@
Design choice: just convert sockaddr_in to ipaddr. no other conversion is required.
{section: Socket connections that do not use class Sock}
+-- StdUnivSock was handled.
StdUnivSock calls do_connect() (condor_util_lib/do_connect.c) to establish connection with the scheduler. Entire code path uses IPv4 specific constant and functions. Should I just convert them or introduce another socket class?
-Current Stream and Sock are somewhat bloated. It is not functionally coherent. Diverse functions are included in single class. The concept "Stream" is a feature of socket. It should not be parent of Sock. This is where multiple interface inheritance kicks in. Consider "IStream" for the functionalities. So, class Sock could remain just socket wrapper.
+
+-- don't mind it
+Current Stream and Sock are somewhat bloated. It is not functionally coherent. Diverse functions are included in single class. The concept "Stream" is a feature of socket. It should not be parent of Sock. This is where multiple interface inheritance kicks in. Consider "IStream" for the functionality So, class Sock could remain just socket wrapper.
{section: Sinful string construction}
There are some places that construct sinful strings without using wrapper functions.
@@ -147,6 +150,8 @@
The caveat is that sinful grammar is changing due to IPv6 address and these are simply incompatible. If the address is IPv6, it should be form of <[%s]:%s>. We need another abstraction layer.
+-- I made a wrapper function. generate_sinful()
+
{section: Where to put NODNS?}
NO_DNS were completely re-implemented. Below are garbages.
@@ -160,18 +165,24 @@
But what I really think is that is it really required? I prefer better abstractions.
+-- NODNS issue was resolved by introducing newer DNS functions.
+
{section: Test required}
Don't forget below lists.
*:Choosing a specific interface for Condor use in multi-homed IPv6 host. Use param "NETWORK_INTERFACE".
+-- All done
+
{section: Converting utility functions}
{subsection: struct hostent}
I Initially only looked at struct sockaddr_in. I wrote class ipaddr for replacement. However, it is only half of the world. I should devise IPv6 compliant structure for struct hostent and make it obsolete. I think it would make more sense if we have class ipaddr and class MyString instead of sockaddr* and char*. Write here some design possibilities!
+-- Ok, all done.
+
{code}
// from MSDN
typedef struct hostent {
@@ -201,8 +212,12 @@
It seems assign() is only used by these Shared* thing. So maybe we could end up with refactoring it.
+-- do not need to think about this
+
{section: List of Condor IP addr functions}
+-- All done here.
+
These are almost done. At some point, should deprecate internet.c and my_hostname.cpp.
{code}
@@ -241,6 +256,8 @@
Condor defines its own netdb-related functions (proxy functions) for its own DNS system called NO_DNS.
+-- all done. reimplemented condor 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.
@@ -294,3 +311,5 @@
{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.
+
+-- I won't do this.
