On Tuesday, April 23, 2013 at 2:25 PM. Timothe Litt wrote: > Thanks for, er, addressing, this. (I'm not sure if I intended the pun, but I > guess I'll leave it.) > > Note that RFC3484 specifies that getaddrinfo returns addresses in 'success > rate' order, with an override (with glibc, that's > /etc/gai.conf). So code can't assume what address type getaddrinfo > will return first; it can be dynamic. And simh shouldn't impose a priority. > Rather, simh should try each address returned by getaddrinfo, in the order > it's returned until one works. This can be quite a few IP addresses if a name > returns multiple A/AAAA records. getaddrinfo's addrinfo struct returns the > associated address family with the > sockaddr. This works for both literal addresses and dns names, so the > code should be simple.
That is great in theory, and exactly how the code was initially written when the dual IPv4 and IPv6 stack support was added. Real world experience on several platforms have necessitated the addition of the existing extended logic. One would argue that the Raspberry Pi's OS exceed the goal of success rate order since it provided answers which could NEVER work on the current system. The order preference which the current code implements is exactly how the answers are presented on well behaved platforms. The platforms for which this was not true could establish a simple single stack listener, but couldn't get the dual stack functionality to work. Users on these platforms 'could' have done the same work around that you suggested for Mark Benson's case, but we'll get fewer complaints and confused users if things 'just work' without any fancy user footwork. > While the string wouldn't have meant much to Mark, it would have saved me > the hassle of first translating the numeric code. And since ERRNO values do > vary by system, it helps to get the string with error reports. > > Yes, windoze doesn't use strerror for sockets; you do something like > WSAGetLastError + FormatMessage to get the error string in that case. Code existed in the Beta version on github to display textual values along with the error code for the cases we've seen regularly. All prior simh versions merely reported any socket errors the way Mark Benson saw it reported initially for every possible socket error. The latest code has been changed to 1) add EAFNOSUPPORT to the list which will always have displayed textually on all platforms, and 2) for non-windows platforms, strerror() is called to provide a string translation along with the numeric error code. In general, simh users should never see these errors. If/when they happen they indicate a programming error which probably needs internal changes to address. Maybe the message should be extended to also suggest that it be reported to the github simh issue system.... - Mark _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
