freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Frediano Ziglio <freddy77 AT gmail.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] ipv6 considerations
- Date: Sun, 21 Aug 2011 11:19:29 +0200
2011/8/19 Peter Deacon <peterd AT iea-software.com>:
> On Fri, 19 Aug 2011, Frediano Ziglio wrote:
>
>> Mmm... I'm just thinking about using getaddrinfo/getnameinfo and
>> similar in libtds avoiding other "old" functions like gethostbyname
>> and implementing getaddrinfo replacements where not available.
>
> Hi Freddy,
>
> I like the idea. If you are starting from the old IPv6 patch..
>
> Was thinking instead of hacking tds_open_socket to try each address it
> would be better to add an addrinfo field to tds_open_socket and call it
> once for each entry until a connection is made or the linked list is
> exhausted. (example rename tds_open_socket to tds_open_socket_addr and
> make tds_open_socket just handle iterating getaddrinfo calls)
>
I think ip_addr and port should be replaced by addrinfo which contains
full address (ip+port). Also I think it would better to to use both
node and service calling getaddrinfo in order to avoid 2 calls, one
for ip and one for port. I personally would remove ip_addr from
TDSLOGIN. server_host_name and port fields are sufficient.
>
> With multiple addresses there are some problems:
>
> The connection level timeout should apply to each address attempted but
> some may want to also be able to constrain the overall time it takes to
> connect.
>
Yes, but for first implementation we could just try all addresses :)
> The better picks based on IPv6 RFC / local policy will be first in the
> linked list however the error message returned via the old patch is always
> from the last attempt.
>
> Some scheme where the first error tried on the list is remembered as long
> as failure reason is not connection refused or no route to host would be
> ideal as it stands a better chance of reporting the connection error for
> the most useful/salient host to the user...or multiple error records?
>
There are a similar code in login.c which save and reply errors.
> Let me know if you want any help.
>
> regards,
> Peter
I think change could be split into 2 patches
- one to provide always getaddrinfo and required functions (configure
tests, replacements where not available and so on);
- one to use addrinfo and connect.
Any help is weolcome.
Frediano
-
[freetds] ipv6 considerations,
Frediano Ziglio, 08/19/2011
-
Re: [freetds] ipv6 considerations,
Christos Zoulas, 08/19/2011
-
Re: [freetds] ipv6 considerations,
Frediano Ziglio, 08/19/2011
- Re: [freetds] ipv6 considerations, Christos Zoulas, 08/19/2011
-
Re: [freetds] ipv6 considerations,
Frediano Ziglio, 08/19/2011
-
Re: [freetds] ipv6 considerations,
Peter Deacon, 08/19/2011
-
Re: [freetds] ipv6 considerations,
Frediano Ziglio, 08/21/2011
- [freetds] Kerberos support, Sergio NNX, 08/21/2011
-
Re: [freetds] ipv6 considerations,
Frediano Ziglio, 08/21/2011
-
Re: [freetds] ipv6 considerations,
Christos Zoulas, 08/19/2011
Archive powered by MHonArc 2.6.24.