> > In the big picture, I think that's the direction we need to move. > But I don't think we want to have every application have that logic, > since the logic might need to evolve over time (and needs to take into > account Alain's example of umpteen different IP addresses - might want > to stagger the attempts when there are lots of IP addresses to try.) > > So instead I think we want to raise the abstraction layer for the > applications by introducing a connect-by-name socket API so that the > application just hands in the FQDN and the port number to which it wants > to connect. > > It isn't hard to come up with an initial cut of a connect-by-name > implementation entirely as a library routine (using non-blocking sockets > for the connect() system calls so that multiple can be outstanding and > the same time.) >
How would this work as a nonblocking connect? A lot of network services can't afford to block, they have other sockets to service. Would it return an fd_set? maybe a poll array? Maybe it would integrate with linux's epoll(), or freebsd's kqueue()? -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
