IPv6 Support
Sabahattin Gucukoglu
Is there any official remark on the support of IPv6 sockets, client
and server, in current Tcl? I would certainly appreciate being able
to listen for connections from IPv6 addresses and don't imagine the
interpreter has to change all that much (the syntax should be the same
for the scripter, at any rate).
Cheers,
Sabahattin
Jeff Hobbs
Yes and no. We (ActiveState) have a patched version that does support
ipv6, but it does require one (minor) change to a public API (change
the meaning of one 'int' argument from single flag to flags). When
making an opening socket request, it doesn't _require_ INET
specification, but you can pass one (e.g. if you only wanted ipv6).
OTOH, server sockets do require it, and you would have to create one
each for ipv4 and ipv6, as you need to bind twice (once to each
stack).
Jeff
dkf
> Yes and no. We (ActiveState) have a patched version that does support
> ipv6, but it does require one (minor) change to a public API (change
> the meaning of one 'int' argument from single flag to flags). When
> making an opening socket request, it doesn't _require_ INET
> specification, but you can pass one (e.g. if you only wanted ipv6).
> OTOH, server sockets do require it, and you would have to create one
> each for ipv4 and ipv6, as you need to bind twice (once to each
> stack).
I thought a listening v6 socket could receive incoming v4 connections?
Or at least that's what I was lead to believe when talking about this
at EuroTcl last week. (A syntax/API change is definitely needed if
we're going to allow people to control whether they use v4 or v6
sockets.)
Donal.
Sabahattin Gucukoglu
If you mean v6-mapped-v4 addresses, yes you can. But I imagined
something more transparent, EG, that binding a server socket simply
bound both v6 :: and v4 0 if otherwise unspecified (in which case, a
given family is supported only). OTOH, we can do an Apple
impersonation with regard to client-side IPv6: try it first when the
resolver reports addresses.
I don't know how much of this will turn out to be POSIx-specific. If
multiplatform is still a concern (even M$ have a UNIX-like subsystem
now in Interix) then life might be a bit harder, but OS X and all
other unixes should be just fine.
On a related note, will Tcl ever want to develop features like fork
and setuid, seeing as how they're platform-specific?
Cheers,
Sabahattin
dkf
gucukoglu.com> wrote:
> If you mean v6-mapped-v4 addresses, yes you can. But I imagined
> something more transparent, EG, that binding a server socket simply
> bound both v6 :: and v4 0 if otherwise unspecified (in which case, a
> given family is supported only). OTOH, we can do an Apple
> impersonation with regard to client-side IPv6: try it first when the
> resolver reports addresses.
For client sockets, we should just ask the system name resolver to
pick which it wants (i.e., so it is up to system policy, which is the
Right Thing). For server sockets, I'd like to know if we can do it
with a single v6 socket or whether we'd need two (one v6, one v4).
> I don't know how much of this will turn out to be POSIx-specific. If
> multiplatform is still a concern (even M$ have a UNIX-like subsystem
> now in Interix) then life might be a bit harder, but OS X and all
> other unixes should be just fine.
The whole I/O layer is completely different on Windows. We don't use
the POSIX APIs on that platform...
> On a related note, will Tcl ever want to develop features like fork
> and setuid, seeing as how they're platform-specific?
They're in the TclX extension and have been for at least 14 years
(probably more; that extension has been around for ages). The setuid()
support will probably remain in an extension (there really isn't that
much code that needs it) and fork() turns out to be incompatible with
POSIX threads in a very nasty way if it isn't followed shortly by
execve(). After many years of indecision, we're going to go with
threads; more useful for modern code and modern hardware.
Donal.
David Gravereaux
> For client sockets, we should just ask the system name resolver to
> pick which it wants (i.e., so it is up to system policy, which is the
> Right Thing). For server sockets, I'd like to know if we can do it
> with a single v6 socket or whether we'd need two (one v6, one v4).
You need two sockets listening on each. The v6 one can have a radically
different path and there really is no direct association to the v4.
Ditto on the resolver doing the work, but with an override so you can
get the 'more right answer' when you need to.