Menu
▾
▴
chromium-dev
|
From: Mike H. <mho...@gr...> - 2004-06-22 00:23:59
|
I noticed that we are trying to include sys/socket.h on ALL platforms. We shouldn't be doing this under Windows. I'll be checking in a fix shortly. The other oddity is that the changes to support IPv6 seem to always kick us into using ADDRINFO on recent versions of Linux. This works, but moves all streams to PF instead of AF. Things work, I just want to point out that this probably shouldn't be default behavior. We probably only really want to kick across to PF streams when actually using IPv6 to connect. -Mike |
|
From: Samuel T. <sam...@en...> - 2004-06-22 08:51:27
|
Hi Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son cl= avier : > The other oddity is that the changes to support IPv6 seem to always kic= k=20 > us into using ADDRINFO on recent versions of Linux. This works, Of course it does, to support IPv6 whenever available. getaddrinfo()'s interface was specially design to always work: the dns lookup may report ipv4 and ipv6 addresses, getaddrinfo() gives them all. If an ipv6 address is given but doesn't work either because lack of support in the kernel (ENOAFSUPPORT) or for network reasons, the connection will revert back to ipv4. > but moves all streams to PF instead of AF. PF / AF ?? That means Protocol Family / Address Family. There's actually no difference between them, except maybe some minor differences in the numbering (there is none under linux for instance), and the *good* one to use for getaddrinfo in the hints structure *is* PF_something, since we tell the Protocol Family we'd like to use for conencting (here, unspecified). Then getaddrinfo may report AF_something to tell which address family it found. I just checked this once again in Gis=E8le Cizault's book "IPv6 Th=E9orie et pratique" > Things work, I just want to point out that this probably shouldn't > be default behavior. We probably only really want to kick across > to PF streams when actually using IPv6 to connect. Currently, we actually *precisely* use PF_INET when not using IPv6 to connect. Regards, Samuel Thibault |
|
From: Mike H. <mho...@gr...> - 2004-06-22 15:28:49
|
Samuel Thibault wrote: >Hi > >Le lun 21 jun 2004 à 17:23:28 -0700, Mike Houston a tapoté sur son clavier : > > >>The other oddity is that the changes to support IPv6 seem to always kick >>us into using ADDRINFO on recent versions of Linux. This works, >> >> > >Of course it does, to support IPv6 whenever available. getaddrinfo()'s >interface was specially design to always work: the dns lookup may >report ipv4 and ipv6 addresses, getaddrinfo() gives them all. If an >ipv6 address is given but doesn't work either because lack of support >in the kernel (ENOAFSUPPORT) or for network reasons, the connection >will revert back to ipv4. > > I understand why it works, I just thought it was odd to ALWAYS use it. > > >>but moves all streams to PF instead of AF. >> >> > >PF / AF ?? >That means Protocol Family / Address Family. > >There's actually no difference between them, except maybe some minor >differences in the numbering (there is none under linux for instance), >and the *good* one to use for getaddrinfo in the hints structure *is* >PF_something, since we tell the Protocol Family we'd like to use for >conencting (here, unspecified). Then getaddrinfo may report >AF_something to tell which address family it found. I just checked >this once again in Gisèle Cizault's book "IPv6 Théorie et pratique" > > I don't have a problem with supporting IPv6 correctly, but some TOE's and most of the IP interception routines for highspeed networks only work if AF_INET is used. For the later, you can use LD_PRELOAD to automatically kick some IP connections to SocketsGM, SDP, IP over Quadrics, etc. But, this only works if AF_INET is used... Since SDP has it's own layer now, this becomes a little less important. > > >>Things work, I just want to point out that this probably shouldn't >>be default behavior. We probably only really want to kick across >>to PF streams when actually using IPv6 to connect. >> >> > >Currently, we actually *precisely* use PF_INET when not using IPv6 to >connect. > > Sorry for the misunderstanding here. My point is whether we should use AF_INET in general and detect IPv6 another way. Is anyone using IPv6? How often does anyone need to run IPv6 across a cluster? Is it really just for remote stream support? -Mike >Regards, >Samuel Thibault > > |
|
From: Samuel T. <sam...@en...> - 2004-06-22 16:08:46
|
Le mar 22 jun 2004 =E0 08:31:25 -0700, Mike Houston a tapot=E9 sur son cl= avier : > Samuel Thibault wrote: > >Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son= clavier=20 > >: > >>The other oddity is that the changes to support IPv6 seem to always k= ick=20 > >>us into using ADDRINFO on recent versions of Linux. This works, > > > >Of course it does, to support IPv6 whenever available. getaddrinfo()'s > >interface was specially design to always work: the dns lookup may > >report ipv4 and ipv6 addresses, getaddrinfo() gives them all. If an > >ipv6 address is given but doesn't work either because lack of support > >in the kernel (ENOAFSUPPORT) or for network reasons, the connection > >will revert back to ipv4. >=20 > I understand why it works, I just thought it was odd to ALWAYS use it. The getaddrinfo() way is quite better in many ways: since it may return several addresses, hosts with multiple ips may be correctly handled: every ip will be tried until one works. > some TOE's and most of the IP interception routines for highspeed > networks only work if AF_INET is used. Ah, ok. For this, just make sure that dns replies don't give any ipv6 address, and it will work. If needed, use a special dns entry. > My point is whether we should use AF_INET in general and detect > IPv6 another way. The user may set IPv6 addresses by hand, but for this, getaddrinfo() must be used. Using getaddrinfo() replies for determining whether IPv6 is possible (or asked by hand) really is the fine way. > Is anyone using IPv6? Yes, some people at the INSA of Lyon actually contacted me because they needed IPv6 working. > How often does anyone need to run IPv6 across a cluster? Well, IPv6 is actually in several ways more efficient that IPv4, and QoS is quite better supported. > Is it really just for remote stream support? I guess people at INSA use Chromium over VTHD, a very high bandwidth WAN used for research. IPv6's QoS is quite useful there for instance. Regards, Samuel Thibault |
|
From: Samuel T. <sam...@en...> - 2004-06-22 08:51:39
|
Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son cl= avier : > I noticed that we are trying to include sys/socket.h on ALL platforms. = =20 > We shouldn't be doing this under Windows. I'll be checking in a fix=20 > shortly. Is netdb.h available under Windows ? It happens to seem to provide AF_INET6 under linux, but I'm really not sure. The tests I could see in configure.in scripts was always to use <sys/socket.h> Regards, Samuel Thibault |
|
From: Mike H. <mho...@gr...> - 2004-06-22 15:29:59
|
Samuel Thibault wrote: >Le lun 21 jun 2004 à 17:23:28 -0700, Mike Houston a tapoté sur son clavier : > > >>I noticed that we are trying to include sys/socket.h on ALL platforms. >>We shouldn't be doing this under Windows. I'll be checking in a fix >>shortly. >> >> > >Is netdb.h available under Windows ? It happens to seem to provide >AF_INET6 under linux, but I'm really not sure. The tests I could see in >configure.in scripts was always to use <sys/socket.h> > > No. Windows doesn't yet support IPv6, at least in a standard posix manner. -Mike |
|
From: Samuel T. <sam...@en...> - 2004-06-22 15:54:48
|
Le mar 22 jun 2004 =E0 08:32:37 -0700, Mike Houston a tapot=E9 sur son cl= avier : > Samuel Thibault wrote: >=20 > >Le lun 21 jun 2004 =E0 17:23:28 -0700, Mike Houston a tapot=E9 sur son= clavier=20 > >: > >>I noticed that we are trying to include sys/socket.h on ALL platforms= . =20 > >>We shouldn't be doing this under Windows. I'll be checking in a fix=20 > >>shortly. > > > >Is netdb.h available under Windows ? It happens to seem to provide > >AF_INET6 under linux, but I'm really not sure. The tests I could see i= n > >configure.in scripts was always to use <sys/socket.h> > >=20 > > > No. Windows doesn't yet support IPv6, at least in a standard posix man= ner. Yes, I know, but netdb.h also provides gethostbyname & co, I wonder where they are defined under Windows. Oops, sorry, misexplaining: I wanted to say that netdb.h seems to include sys/socket.h itself so that we could replace #include <sys/socket.h> by #include <netdb.h> and remove #ifndef WIN, but for this, netdb.h is needed even in windows. Regards, Samuel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X