headers
Gregor Jasny | 3 Feb 2009 18:45
Picon

Re: IPv6 servers redux

Hi,

I've found some time to look at the IPv6 servers patch.

On Wed, Jan 14, 2009 at 02:23:01PM +0100, Daniel Stenberg wrote:
> On Thu, 18 Dec 2008, Gregor Jasny wrote:
> It struck me that the API for ares_get_servers() is not really solid. How
> would a user free the list of servers again? We can't assume that free() is
> fine on memory returned from c-ares.
> 
> Would it perhaps make sense to fill in a given buffer instead of doing a
> malloc, and then do a 'too small buffer' return code if the buffer isn't 
> large
> enough to hold the full list? The other solution is of course to make a more
> generic ares_free() function that would free the given resource. It could 
> then
> be made somewhat genericly so that it can be used for future returned data 
> as well...

I've created ares_free(), a simple wrapper around free(). I think that
will do it for now.

I've tested DNS lookup as usual via adig with IPv4 and IPv6.

Thanks,
Gregor
Attachment (servers-3.patch): text/x-diff, 21 KiB
Permalink | Reply | 1 comment |
headers
Daniel Stenberg | 3 Feb 2009 19:54
Picon
Favicon
Gravatar

Re: IPv6 servers redux

On Tue, 3 Feb 2009, Gregor Jasny wrote:

Thanks for the update!

> I've created ares_free(), a simple wrapper around free(). I think that will 
> do it for now.

Right, but I'd then prefer if the data ares_get_servers() return somehow is 
identifiable as such data. Like an int field with an identifier first in the 
struct or similar.

The idea I'm having is that even in the future when we introduce more 
ares_get_*() functions that possibly return all sorts of various structs that 
have one or more allocs associated to it, we can use ares_free() to free all 
such data - if and only if we can identify the particular data in the 
ares_free() call itself.

> +#if !defined(HAVE_STRUCT_IN6_ADDR) && !defined(s6_addr)
> +struct in6_addr {
> +  union {
> +    unsigned char _S6_u8[16];
> +  } _S6_un;
> +};
> +#define s6_addr _S6_un._S6_u8
> +#endif

This must be wrong. It brings back the struct I renamed to ares_in6_addr and 
it brings back the (bad) dependency on HAVE_STRUCT_IN6_ADDR which I already 
removed from the public header file!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Simak | 11 Feb 2009 12:39
Picon

Reusing of ares_channel

Hi,

We want to reuse ares_channel objects for optimization purposes. 

Is there any possible issues with reusing ares_channel?
How long ares_channel holds connection if TCP is used?

Thanks,
Alexey Simak
Permalink | Reply | 1 comment |
headers
Daniel Stenberg | 11 Feb 2009 13:33
Picon
Favicon
Gravatar

Re: Reusing of ares_channel

On Wed, 11 Feb 2009, Alexey Simak wrote:

> We want to reuse ares_channel objects for optimization purposes.
>
> Is there any possible issues with reusing ares_channel?

Not that I know. That's what we've been doing in libcurl for years.

> How long ares_channel holds connection if TCP is used?

There's no time limit at all.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 0 comments |
headers
Alexey Simak | 12 Feb 2009 14:29
Picon

Problem in adig when used both ARES_FLAG_USEVC and ARES_FLAG_STAYOPEN flags.

Hi,

adig hangs when both ARES_FLAG_USEVC and ARES_FLAG_STAYOPEN
flags are used.

Reason: 
Since tcp socket is not closed when all queries are done 
ares_fds() functions sets tcp socket to read_fds and returns 1.
So we leave the next loop only if server closes the connection:

  /* Wait for all queries to complete. */
  while (1)
    {
      FD_ZERO(&read_fds);
      FD_ZERO(&write_fds);
      nfds = ares_fds(channel, &read_fds, &write_fds);
      if (nfds == 0) {
        break;
      }
      tvp = ares_timeout(channel, NULL, &tv);
      count = select(nfds, &read_fds, &write_fds, NULL, tvp);
      if (count < 0 && SOCKERRNO != EINVAL)
        {
          perror("select");
          return 1;
        }
      ares_process(channel, &read_fds, &write_fds);
    }

Is there any other way we can be notified that all queries
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Stenberg | 13 Feb 2009 10:46
Picon
Favicon
Gravatar

Re: Problem in adig when used both ARES_FLAG_USEVC and ARES_FLAG_STAYOPEN flags.

On Thu, 12 Feb 2009, Alexey Simak wrote:

> adig hangs when both ARES_FLAG_USEVC and ARES_FLAG_STAYOPEN flags are used.
>
> Since tcp socket is not closed when all queries are done ares_fds() 
> functions sets tcp socket to read_fds and returns 1. So we leave the next 
> loop only if server closes the connection:

Right, the loop can't assume that it should continue as long as there are 
sockets if there are always at least one.

I figure you need to make the loop terminate based on response from the DNS 
server or a timeout or similar.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 0 comments |

Gmane