liblo-devel Mailing List for LibLO

On 11 oct. 2011, at 21:07, Stephen Sinclair wrote:

> Just waiting to get a chance to do some more testing on this issue, on
> a Mac. I will probably have some time this week.

Thanks Steve, let me know if I can help in any way.


Cam

Just waiting to get a chance to do some more testing on this issue, on
a Mac. I will probably have some time this week.

Steve

On Mon, Oct 3, 2011 at 3:49 AM, Camille Troillard <ca...@os...> wrote:
>
> On 3 oct. 2011, at 05:53, Stephen Sinclair wrote:
>
>> Since my last email I have been trying to figure out whether this
>> iteration is truly needed, or whether we can determine upfront which
>> of the returned addresses matches best.  In general I think the
>> connectionless nature of UDP means that checking the return code of
>> sendto() as the basis for iteration over addrinfo is problematic.
>>
>> I have now been doing similar tests, so I thought I should try to
>> write down the results, as it might make a nice reference sheet.  I
>> have been playing with the specified families of the server and
>> client, and how it works with the hostname format.  These tests were
>> done on my EEEPC running Ubuntu 10.10.
>>
>> With ENABLE_IPV6, and PF_UNSPEC as the hint for getaddrinfo at client,
>> if the server is initialized with PF_INET (IPv4):
>>
>> - client sends to "127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET
>>  message is received as usual
>>
>> - client sends to "::FFFF:127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message is received
>>
>> - client sends to "::1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message is NOT received, expected
>>  sendto() does not return an error
>>
>> - client sends to "localhost"
>>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>>  message is NOT received on first address, second address is NOT
>> TRIED because sendto() does not return error
>>  message IS received if I force it to use the second address (AF_INET)
>>
>> Similarly with PF_UNSPEC at client, if the server is initialized with
>> PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned ON.
>>
>> - client sends to "127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET
>>  message is NOT received, expected
>>  sendto() does not return an error
>>
>> - client sends to "::FFFF:127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message is NOT received, expected
>>  sendto() does not return an error
>>
>> - client sends to "::1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message is received
>>
>> - client sends to "localhost"
>>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>>  message is received on first address
>>  message is NOT received if I force it to use the second address
>> (AF_INET), expected
>>
>> Finally with PF_UNSPEC at client, if the server is initialized with
>> PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned OFF.
>>
>> - client sends to "127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET
>>  message IS received
>>
>> - client sends to "::FFFF:127.0.0.1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message IS received
>>
>> - client sends to "::1"
>>  getaddrinfo returns 1 address, family AF_INET6
>>  message is received
>>
>> - client sends to "localhost"
>>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>>  message is received on first address
>>  message IS ALSO received if I force it to use the second address (AF_INET)
>>
>> So, I think this makes the behaviour of IPV6_V6ONLY pretty clear.
>> However, it also indicates that checking the return code of sendto()
>> is not the right way to choose which address to use if more than one
>> is available.  In fact, to select, it seems to be really necessary to
>> explicitly know whether the receiver is IPv4 or IPv6, then if two
>> addresses are returned the correct one can be chosen.  But I'm not
>> sure what to do in the case where this is unknown by the client.  The
>> obvious thing is to disable IPV6_V6ONLY, in which case it should "just
>> work", but this means the client depends on the server having this
>> flag disabled.
>
> That is a very good point.
>
> However, I just tested, and the behavior on Mac OS X 10.6.8 seems a bit different.
> With PF_UNSPEC at the client, and IPV6_V6ONLY disabled on the server, without looping over the results of getaddrinfo, sendto returns an error 22.
>
> So in my opinion, iterating is still necessary.
>
> ----
> I just discovered one very curious and unexpected behavior:
>
> I can launch one server with IPV6_V6ONLY on port XYZW, and an IPV4 only server on the same port.  I was not expecting this!  The result is that every client request configured with explicit IPv4 address are sent to the IPv4 server, and all other (including osc://localhost:XYZW) are sent to the other server.
>
> When I stopped my IPv6 server, all the requests were then sent to the IPv4 server, even if the address was specified as a IPv6 address.
> ----
>
>
>> It's possible to specify IPv4 or IPv6 by the structure of the
>> numerical IP string, but in the case where a hostname is given I'm not
>> sure how to specify "connect to this host by IPv6".  Perhaps it's
>> supposed to be up to the name resolution service to decide for you?
>> (Like, if you browse to an IPv6 website is it up to the DNS server to
>> inform the system to connect via IPv6?)
>
> Yes, in my opinion this is the job of the DNS service.
>
>
>> Anyways, maybe a good-enough solution is just to always select IPv6 if
>> it is available, and maybe let this be overridden at runtime if IPv4
>> needs to be selected.  (e.g. lo_address_enable_ipv6(boolean))
>
> Since sento does not return an error on Linux, this would be a good solution, but on Mac OS X this option would not be needed if we loop over the results of getaddrinfo.  Do you think both solutions (lo_address_enable_ipv6 and iteration) work together?
>
>
>> Also, I notice the sscanf incantations in the URL parsing code may not
>> be quite up to the job of accepting URLs like "osc.udp://[::1]:9000",
>> so that might need looking at.
>
> I am not sure of this, it looks like the second statement in lo_url_get_hostname correctly takes in account bracket characters.  Do you see another case where this would not work?
>
>
> As a last note, I noticed that the code I added to prepend ::FFFF: to IPv4 dotted addresses when IPv6 is enabled was not taking in account the NUL character.  In address.c at line 386, the correction is:
>
> #ifdef ENABLE_IPV6
>        hints.ai_family = PF_UNSPEC;
>
>        if (is_dotted_ipv4_address(a->host)) {
>                size_t len = strlen(a->host) + 1;
>                host = calloc(len + 7, sizeof(char));
>                strcpy(host, "::FFFF:");
>                strncpy(host + 7, a->host, len);
>        }
> #else
>
>
>
> ---
> Cam
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

On 3 oct. 2011, at 05:53, Stephen Sinclair wrote:

> Since my last email I have been trying to figure out whether this
> iteration is truly needed, or whether we can determine upfront which
> of the returned addresses matches best.  In general I think the
> connectionless nature of UDP means that checking the return code of
> sendto() as the basis for iteration over addrinfo is problematic.
> 
> I have now been doing similar tests, so I thought I should try to
> write down the results, as it might make a nice reference sheet.  I
> have been playing with the specified families of the server and
> client, and how it works with the hostname format.  These tests were
> done on my EEEPC running Ubuntu 10.10.
> 
> With ENABLE_IPV6, and PF_UNSPEC as the hint for getaddrinfo at client,
> if the server is initialized with PF_INET (IPv4):
> 
> - client sends to "127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET
>  message is received as usual
> 
> - client sends to "::FFFF:127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message is received
> 
> - client sends to "::1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message is NOT received, expected
>  sendto() does not return an error
> 
> - client sends to "localhost"
>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>  message is NOT received on first address, second address is NOT
> TRIED because sendto() does not return error
>  message IS received if I force it to use the second address (AF_INET)
> 
> Similarly with PF_UNSPEC at client, if the server is initialized with
> PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned ON.
> 
> - client sends to "127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET
>  message is NOT received, expected
>  sendto() does not return an error
> 
> - client sends to "::FFFF:127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message is NOT received, expected
>  sendto() does not return an error
> 
> - client sends to "::1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message is received
> 
> - client sends to "localhost"
>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>  message is received on first address
>  message is NOT received if I force it to use the second address
> (AF_INET), expected
> 
> Finally with PF_UNSPEC at client, if the server is initialized with
> PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned OFF.
> 
> - client sends to "127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET
>  message IS received
> 
> - client sends to "::FFFF:127.0.0.1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message IS received
> 
> - client sends to "::1"
>  getaddrinfo returns 1 address, family AF_INET6
>  message is received
> 
> - client sends to "localhost"
>  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
>  message is received on first address
>  message IS ALSO received if I force it to use the second address (AF_INET)
> 
> So, I think this makes the behaviour of IPV6_V6ONLY pretty clear.
> However, it also indicates that checking the return code of sendto()
> is not the right way to choose which address to use if more than one
> is available.  In fact, to select, it seems to be really necessary to
> explicitly know whether the receiver is IPv4 or IPv6, then if two
> addresses are returned the correct one can be chosen.  But I'm not
> sure what to do in the case where this is unknown by the client.  The
> obvious thing is to disable IPV6_V6ONLY, in which case it should "just
> work", but this means the client depends on the server having this
> flag disabled.

That is a very good point.

However, I just tested, and the behavior on Mac OS X 10.6.8 seems a bit different.
With PF_UNSPEC at the client, and IPV6_V6ONLY disabled on the server, without looping over the results of getaddrinfo, sendto returns an error 22.

So in my opinion, iterating is still necessary.

----
I just discovered one very curious and unexpected behavior:

I can launch one server with IPV6_V6ONLY on port XYZW, and an IPV4 only server on the same port.  I was not expecting this!  The result is that every client request configured with explicit IPv4 address are sent to the IPv4 server, and all other (including osc://localhost:XYZW) are sent to the other server.

When I stopped my IPv6 server, all the requests were then sent to the IPv4 server, even if the address was specified as a IPv6 address.
----


> It's possible to specify IPv4 or IPv6 by the structure of the
> numerical IP string, but in the case where a hostname is given I'm not
> sure how to specify "connect to this host by IPv6".  Perhaps it's
> supposed to be up to the name resolution service to decide for you?
> (Like, if you browse to an IPv6 website is it up to the DNS server to
> inform the system to connect via IPv6?)

Yes, in my opinion this is the job of the DNS service.


> Anyways, maybe a good-enough solution is just to always select IPv6 if
> it is available, and maybe let this be overridden at runtime if IPv4
> needs to be selected.  (e.g. lo_address_enable_ipv6(boolean))

Since sento does not return an error on Linux, this would be a good solution, but on Mac OS X this option would not be needed if we loop over the results of getaddrinfo.  Do you think both solutions (lo_address_enable_ipv6 and iteration) work together?


> Also, I notice the sscanf incantations in the URL parsing code may not
> be quite up to the job of accepting URLs like "osc.udp://[::1]:9000",
> so that might need looking at.

I am not sure of this, it looks like the second statement in lo_url_get_hostname correctly takes in account bracket characters.  Do you see another case where this would not work?


As a last note, I noticed that the code I added to prepend ::FFFF: to IPv4 dotted addresses when IPv6 is enabled was not taking in account the NUL character.  In address.c at line 386, the correction is:

#ifdef ENABLE_IPV6
        hints.ai_family = PF_UNSPEC;

	if (is_dotted_ipv4_address(a->host)) {
		size_t len = strlen(a->host) + 1;
		host = calloc(len + 7, sizeof(char));
		strcpy(host, "::FFFF:");
		strncpy(host + 7, a->host, len);
	}
#else



---
Cam

On Fri, Sep 30, 2011 at 12:40 PM, Camille Troillard
<ca...@os...> wrote:
> Here is what I found so far:
>
> I still don't understand why setting an option on a server socket would have an interaction on other client sockets.  Anyway, when dealing with IPv6 settings I guess the IP stack has to run one defined "mode", and that the IPV6_V6ONLY option has a global side-effect.  I'm no socket programming expert, so please take the last statement lightly.
>
> While running liblo with the IPV6_V6ONLY option off, I managed to receive data from IPv4 and IPv6 protocols.  But I was unable to send messages on IPv4, only IPv6.
>
> The reason I think is because of the way getaddrinfo is used.  This call returns multiple results in the form of a linked list of addrinfo, which should be iterated until send or sendto does not fails.
>
> I understand that this is not what happens in send.c at line 440.  Only the first item of the addrinfo structure is used.
>
> I have not tested yet if iterating over the getaddrinfo results would solve the problem, but I have the feeling that it would be a great test for a start.
>
> Stephen, do you have any recommendation regarding how I can implement this?
> It seems the result from getaddrinfo is stored in lo_address, so I guess it should be easy to implement the iteration.

Since my last email I have been trying to figure out whether this
iteration is truly needed, or whether we can determine upfront which
of the returned addresses matches best.  In general I think the
connectionless nature of UDP means that checking the return code of
sendto() as the basis for iteration over addrinfo is problematic.

I have now been doing similar tests, so I thought I should try to
write down the results, as it might make a nice reference sheet.  I
have been playing with the specified families of the server and
client, and how it works with the hostname format.  These tests were
done on my EEEPC running Ubuntu 10.10.

With ENABLE_IPV6, and PF_UNSPEC as the hint for getaddrinfo at client,
if the server is initialized with PF_INET (IPv4):

- client sends to "127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET
  message is received as usual

- client sends to "::FFFF:127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET6
  message is received

- client sends to "::1"
  getaddrinfo returns 1 address, family AF_INET6
  message is NOT received, expected
  sendto() does not return an error

- client sends to "localhost"
  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
  message is NOT received on first address, second address is NOT
TRIED because sendto() does not return error
  message IS received if I force it to use the second address (AF_INET)

Similarly with PF_UNSPEC at client, if the server is initialized with
PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned ON.

- client sends to "127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET
  message is NOT received, expected
  sendto() does not return an error

- client sends to "::FFFF:127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET6
  message is NOT received, expected
  sendto() does not return an error

- client sends to "::1"
  getaddrinfo returns 1 address, family AF_INET6
  message is received

- client sends to "localhost"
  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
  message is received on first address
  message is NOT received if I force it to use the second address
(AF_INET), expected

Finally with PF_UNSPEC at client, if the server is initialized with
PF_INET6 (IPv6), and with IPV6_V6ONLY explicitly turned OFF.

- client sends to "127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET
  message IS received

- client sends to "::FFFF:127.0.0.1"
  getaddrinfo returns 1 address, family AF_INET6
  message IS received

- client sends to "::1"
  getaddrinfo returns 1 address, family AF_INET6
  message is received

- client sends to "localhost"
  getaddrinfo returns 2 addresses, family AF_INET6 and AF_INET respectively
  message is received on first address
  message IS ALSO received if I force it to use the second address (AF_INET)

So, I think this makes the behaviour of IPV6_V6ONLY pretty clear.
However, it also indicates that checking the return code of sendto()
is not the right way to choose which address to use if more than one
is available.  In fact, to select, it seems to be really necessary to
explicitly know whether the receiver is IPv4 or IPv6, then if two
addresses are returned the correct one can be chosen.  But I'm not
sure what to do in the case where this is unknown by the client.  The
obvious thing is to disable IPV6_V6ONLY, in which case it should "just
work", but this means the client depends on the server having this
flag disabled.

It's possible to specify IPv4 or IPv6 by the structure of the
numerical IP string, but in the case where a hostname is given I'm not
sure how to specify "connect to this host by IPv6".  Perhaps it's
supposed to be up to the name resolution service to decide for you?
(Like, if you browse to an IPv6 website is it up to the DNS server to
inform the system to connect via IPv6?)

Anyways, maybe a good-enough solution is just to always select IPv6 if
it is available, and maybe let this be overridden at runtime if IPv4
needs to be selected.  (e.g. lo_address_enable_ipv6(boolean))

Also, I notice the sscanf incantations in the URL parsing code may not
be quite up to the job of accepting URLs like "osc.udp://[::1]:9000",
so that might need looking at.

Steve

On Sun, Oct 2, 2011 at 6:23 PM, Camille Troillard <ca...@os...> wrote:
> Hi Stephen,
>
>
> Thank you for coming back to me so promptly.
>
>
> On 2 oct. 2011, at 23:40, Stephen Sinclair wrote:
>
>> Some comments,
>>
>> - There's a small typo in your sscanf line, an extra unicode
>> double-quotation mark seems to have snuck in there.
>
> Oops, thanks for noticing that.
> I later saw that the function should rather include a test to ensure that all formats were parsed:
>
> int is_dotted_ipv4_address (const char* address)
> {
>        int a[4];
>        return sscanf(address, "%u.%u.%u.%u", &a[0], &a[1], &a[2], &a[3]) == 4;
> }

Okay, I changed it, good catch!

>> - For SO_NOSIGPIPE, I prefer to just check for the presence of the
>> option itself instead of checking __APPLE__.  (i.e. #ifdef
>> SO_NOSIGPIPE)
>
> Ah, sorry I was not aware that this could be checked.
> I guess this is it something configure provides, right?

No, it's just that it happens that SO_NOSIGPIPE is a preprocessor
define (in sys/socket.h) so it's easy enough to use the preprocessor
to check for it.  Ultimately it doesn't make a difference but as much
as possible I like to stick to the convention of "check for features"
rather than "check the OS version".

> Yes, I believe that if a working address is found then it should be cached to avoid the loop each time.
>
> In the case of UDP (sendto), I am not sure to know how this can be checked before sendto is called.  Maybe the caching could occur when a successful sendto is made.
>
> In the case of TCP (send), I saw that the iteration I added was a bit stupid because it actually does not change anything, so it should be removed and transferred to send.c in create_socket, around the call to connect.

Okay great, I'll do this modification and see how it works.  It may be
that it's just as easy to use the same code for UDP as TCP.  Although
I just realized there's actually another call to send() for the TCP
case before your loop (to send the message length), so maybe it
wouldn't have made a difference :)

Anyways I'll let you know when I apply the patch and we can test it to
make sure it doesn't introduce any problems.  I'll have to find time
to test on Windows too I guess, but I don't foresee issues there.  (At
least not with this patch... there seems to be some problems with
opening UDP ports on Windows 7, but that's another thing.)

thanks!

Steve

Hi Stephen,


Thank you for coming back to me so promptly.


On 2 oct. 2011, at 23:40, Stephen Sinclair wrote:

> Some comments,
> 
> - There's a small typo in your sscanf line, an extra unicode
> double-quotation mark seems to have snuck in there.

Oops, thanks for noticing that.
I later saw that the function should rather include a test to ensure that all formats were parsed:

int is_dotted_ipv4_address (const char* address)
{
	int a[4];
	return sscanf(address, "%u.%u.%u.%u", &a[0], &a[1], &a[2], &a[3]) == 4;
}



> - In your change to lo_address_resolve(), I think "host" will be NULL
> in the case that "a->host" is not a dotted quad.  In any case, since a
> dotted-quad can only be a string with a limited length, using the
> stack instead calloc would avoid the need to deal with free() for the
> case where host!=a->host.

Yes.


> - For SO_NOSIGPIPE, I prefer to just check for the presence of the
> option itself instead of checking __APPLE__.  (i.e. #ifdef
> SO_NOSIGPIPE)

Ah, sorry I was not aware that this could be checked.
I guess this is it something configure provides, right?


> - Regarding your iteration over the addrinfo list in send_data(): in
> the other thread you mentioned that iterating over addrinfo is
> necessary, and I agree this should be done, but I wonder if ultimately
> once the correct addrinfo is found it can be always reused.  It would
> be nice to determine this during lo_address_resolve() instead of on
> every send.  But maybe the correct one cannot be determined until
> send() is called, in that case maybe the choice could be cached, what
> do you think?  ( e.g. "if (ai!=NULL) a->ai = ai;", of course this
> would have to be handled correctly in lo_address_free().)

Yes, I believe that if a working address is found then it should be cached to avoid the loop each time.

In the case of UDP (sendto), I am not sure to know how this can be checked before sendto is called.  Maybe the caching could occur when a successful sendto is made.

In the case of TCP (send), I saw that the iteration I added was a bit stupid because it actually does not change anything, so it should be removed and transferred to send.c in create_socket, around the call to connect.




Best,
Cam

Thanks Camille!

Some comments,

- There's a small typo in your sscanf line, an extra unicode
double-quotation mark seems to have snuck in there.

- In your change to lo_address_resolve(), I think "host" will be NULL
in the case that "a->host" is not a dotted quad.  In any case, since a
dotted-quad can only be a string with a limited length, using the
stack instead calloc would avoid the need to deal with free() for the
case where host!=a->host.

- For SO_NOSIGPIPE, I prefer to just check for the presence of the
option itself instead of checking __APPLE__.  (i.e. #ifdef
SO_NOSIGPIPE)

- Regarding your iteration over the addrinfo list in send_data(): in
the other thread you mentioned that iterating over addrinfo is
necessary, and I agree this should be done, but I wonder if ultimately
once the correct addrinfo is found it can be always reused.  It would
be nice to determine this during lo_address_resolve() instead of on
every send.  But maybe the correct one cannot be determined until
send() is called, in that case maybe the choice could be cached, what
do you think?  ( e.g. "if (ai!=NULL) a->ai = ai;", of course this
would have to be handled correctly in lo_address_free().)

The first 3 points I have fixed myself, but just wondering about your
opinion on the last point before I commit.

thanks,
Steve

On Fri, Sep 30, 2011 at 6:57 PM, Camille Troillard
<ca...@os...> wrote:
> Here is a more complete patch that includes the previous fixes, and addresses the 'dotted-quad' issue described below.
>
> When ENABLE_IPV6 is defined, during lo_address_resolve, we check is the hostname is a dotted-quad, and if it is, prepend ::FFFF: and use the updated hostname as an argument to getaddrinfo.
>
> This has been tested under Mac OS X 10.6.8.
> Feel free to send your suggestions.
>
>
> Cam
>
>
>
> On 30 sept. 2011, at 19:35, Camille Troillard wrote:
>
>> Here your patch Stephen !
>> It was actually easier to implement than I thought.
>>
>> What this patch does:
>>
>> 1. Prevent SIGPIPE on Mac OS X.
>> 2. Enable dual mode IPv4 + IPv6 listening socket.
>> 3. Iterate over addrinfo results.
>>
>> One important caveat though:
>>
>> When ENABLE_IPV6 is defined, IPv4 addresses must be mapped to IPv6. getadfrinfo does not that automatically.
>>
>> For example 127.0.0.1 becomes ::FFFF:127.0.0.1.
>>
>> Therefore av 4 OSC URL that looks like this:
>>
>>       osc.udp://192.168.1.82:8000
>>
>> Will have to be written this way:
>>
>>       osc.udp://[::FFFF:192.168.1.82]:8000
>>
>> I think that this is not a big deal.
>> We can add some code that automatically detected IP address with dotted notation, and prepend the v6 mapping before passing the host string to getaddrinfo.
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>