Skip to Content.
Sympa Menu

freetds - Re: [freetds] ipv6 considerations

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • 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




Archive powered by MHonArc 2.6.24.

Top of Page