> This is what our implementation does. Not too surprisingly the
>behavior below doesn't match what I said our implementation did. It is
>quite a bit more restrictive than I had remembered.
>wild4 then wild6
> bind socket for 0.0.0.0/8888
> bind socket for ::/8888
> failed bind for ::/8888, Address already in use
>wild6 then wild4
> bind socket for ::/8888
> bind socket for 0.0.0.0/8888
> failed bind for 0.0.0.0/8888, Address already in use
thanks, doesn't the "wild4 then wild6" entry cause some problem
for you?
actually, if we have bind(2) ordering constraint in the kernel,
the order of return value from getaddrinfo(3) has to be carefully
designed - in your case, I bet you need to return AF_INET6 first on
AI_PASSIVE getaddrinfo lookup.
itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
