To me, it sounds like option 4 of using IPV4 mapped to IPV6 is the cleanest way to implement this.  I'm wondering if we might want to take the approach used with oodialog and separate the rxsock library from the interpreter release.  The Windows installer could then check the prereqs to ensure it can be installed on that system.  I'd hate for somebody to be unable to install the entire interpreter because their system didn't have the prereqs for something they might not even need. 


On Mon, Feb 10, 2014 at 4:28 PM, David Ashley <> wrote:
Time for some discussion about how to implement IPv6 for rxsock. There
are some fundamental questions about how to implement this in order to
keep the library functions compatible between IPv4 and IPv6. The
following are some discussion points.

1. As always, the Windows implementation of IPv6 will cause us some
pain. We really need to use the latest version of .Net in order to get
some order of compatibility between Linux and Unix. Early version of
Windows IPv6 used something called "dual mode" in order for IPv6 sockets
to communicate to IPv4 sockets. This was dropped in later versions
of .Net for functionality which closely maps the Lniux implementation.
So I think we need to specify the version of .Net that needs to be
installed on the Windows client/server so that we do not have to figure
out which version of .Net we have and then program around any

2. The really big question is one rsock library or two? There are good
reasons for either answer to this question. A single library actually
makes it both easier and harder on the user. On the one hand the changes
to their source code are smaller with a single library but it also make
it the user's responsibility to manage IPv6 and IPv4 sockets if they use
both in their program and this can be very hard and is completely
unforgiving by the sockets APIs. Two libraries means two code bases for
the developers but also allows for optimized code for each library. On
the down side the IPv6 library will need new function names so that both
libraries can live together in the same ooRexx function name space.

3. There are some sockets APIs in IPv4 that should not be used in IPv6.
We can program around this without much trouble so the user's code need
not change to accommodate the new replacement APIs.

4. This last point may be the biggest. It is possible to completely
convert an application in the rxsock to an IPv6 application without the
users knowledge no matter what kind of network they reside on. In other
words, an IPv4 network can be treated as an IPv6 network by the rxsock
library without the user's knowledge. It can do this by using a "mapped"
interface for the IPv4 addresses. All we need to do is detect an IPv4
network address (an x.x.x.x type address) and convert it to a mapped
address for IPv6 (an easy function to write). And DNS name-to-address
conversion is supplied by the IPv6 APIs (they can supply an IPv6 mapped
address). So it is possible for us to completely convert rxsock to use
IPv6 only without impact to the user.

I got a little long winded here but I want all these points to be
considered before we tackle the rxsock conversion. And there may be more
that will come up later, but I think these are the ones we need to make
decisions on before we get started.

Oh, and I deliberately did not specify what my preferences are so that
you are not influenced by my knowledge of IPv6, which is really quite
basic at the current time.

David Ashley

Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
Oorexx-devel mailing list