From: David A. <w.d...@gm...> - 2014-02-10 21:28:59
|
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 limitations. 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 |
From: Rick M. <obj...@gm...> - 2014-02-10 23:00:17
|
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. Rick On Mon, Feb 10, 2014 at 4:28 PM, David Ashley <w.d...@gm...>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 > limitations. > > 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. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: David A. <w.d...@gm...> - 2014-02-11 01:50:49
|
While I like option 4 there are some things that need to be checked out. For instance, will this option work when there is no set up for IPv6 on the adapter? So far I have not been able to determine that from anything I have read. I am sure there are some other things to check out as well. As to separating rxsock from the release, I am unsure about that one. We need to determine exactly which .Net version we would require and find out if that version was installed with Windows Vista. If it was, then there is really no problem as we would not support any Windows version prior to that anyway. And there would be no need to separate it for Linux as the needed functionality has been there since Linux supported Ipv6. David Ashley On Mon, 2014-02-10 at 18:00 -0500, Rick McGuire wrote: > 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. > > > Rick > > > On Mon, Feb 10, 2014 at 4:28 PM, David Ashley > <w.d...@gm...> 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 > limitations. > > 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. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > ------------------------------------------------------------------------------ > 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. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Mark M. <mie...@gm...> - 2014-02-11 15:46:58
|
On Mon, Feb 10, 2014 at 3:00 PM, Rick McGuire <obj...@gm...> wrote: > 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. > > I haven't joined into the discussion much because I simply don't know much about socket programming. But, I think Rick's last point is valid, It would be a shame if some of the old dinosaurs couldn't install a newer version of ooRexx because of a dependency on a version of .Net that is a later version of what comes with the version of Windows they are using. One of the thoughts I had before David posted the beginning of this thread is that maybe we could use this opportunity to update rxsock itself, so that it better uses the newish APIs and is object orientated than rather than procedural. One possibility would be leave rxsock just as it is and take the code base use it to produce a new extension that supports both IPv4 and IPv6. This new extension could be a separate install, like ooDialog can be installed separately. Users that want IPv6 support could install it, users that didn't want IPv6 could just stick with rxsock. I'm in favor of that, but since David is pushing this, I'm perfectly fine with whatever he wants to do. -- Mark Miesfeld |
From: Mike C. <mf...@sp...> - 2014-02-11 16:06:20
|
One of the thoughts I had before David posted the beginning of this thread is that maybe we could use this opportunity to update rxsock itself, so that it better uses the newish APIs and is object orientated than rather than procedural. Upwards-compatible could be tricky. Maybe just add a new library ('rxsock6'?) which is unencumbered by past history. Mike |
From: Mark M. <mie...@gm...> - 2014-02-11 16:23:13
|
On Tue, Feb 11, 2014 at 8:06 AM, Mike Cowlishaw <mf...@sp...> wrote: > > Maybe just add a new library ('rxsock6'?) which is unencumbered by past > history. > > Well, that is really more of what I meant. A new extension that was unencumbered by the original rxsock design. But one that supported both IPv4 and IPv6. -- Mark Miesfeld |
From: Bill T. W. <wb...@ar...> - 2014-02-11 18:13:13
|
I kinda like Mike's suggestion, to have a new set of functions to support IP6. Now if the newer IP6 stuff can work correctly in IP4 or IP6 then I think we have a winner. Existing stuff would continue to work under IP4, and when an applications code is converted to use the new IP6 functions it might still work in an IP4 only environment. Have a newer set of functions also addresses Mark's comment of being more object oriented, rather than "procedural"... That way I do not have to change the ooRexx programs that I have already written that use IP4. When I want to support IP6, I can modify the code as needed to make use of the newer IP6 support. With separate libraries, as a designer, I can choose which way I want to go.... I see some problems with requiring a newer version of ".net", because I know of a number of companies that are not ready to convert to newer releases beyond WINXP, even though they will not have any official "support". Sometimes, this is a financial issue (new hardware, new software, training, etc.), and in other cases it is because they do not have the staff to oversee an orderly conversion. Requiring a newer version of .NET might make some applications to be not available on an older system and/or a older application to not be available on a newer version of Windows. You also have the "special" case of anybody who uses WINXP under a virtual machine to support applications that have not been converted to a newer Windows environment (or that are not available under Linux). Compatability issues can be, and frequently are, complex - For Instance, I have found a number of little applications that say they work under Windows 8.1 - and they don't, unless the target system has a real touch screen - particularly error message pop-up screens that are longer then the laptop's screen height with an "OK" button at the bottom of the window.... With a touch screen you can "slide" the window up, but unless the designer provided for the old scroll bars as well, you can't scroll the windows with your mouse or cursor buttons. This also applies to Linux environments, which as we know, are not all the same... i.e. Ubuntu's newer screen manager environments... or Gnome 2 -vs- Gnome 3 -vs- KDE - vs- whatever. My vote? consider doing the IP6 under a newer set of functions. /s/ Bill Turner, wb4alm On 02/11/2014 11:06 AM, Mike Cowlishaw wrote: > > One of the thoughts I had before David posted the beginning of > this thread is that maybe we could use this opportunity to update > rxsock itself, so that it better uses the newish APIs and is > object orientated than rather than procedural. > Upwards-compatible could be tricky. > > Maybe just add a new library ('rxsock6'?) which is unencumbered by > past history. > Mike > > |
From: Michael L. <ml...@lu...> - 2014-02-11 03:58:33
|
David Ashley wrote: > 1. As always, the Windows implementation of IPv6 will cause us some > pain. We really need to use the latest version of .Net IPv6 within Windows does not have a native C/C++ interface, only .Net? Blessings, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ |
From: David A. <w.d...@gm...> - 2014-02-11 13:46:19
|
There is a native TCP/IP API for Windows. However, older versions of Windows do not have the TCP/IP functionality we need, some of the APIs work differently than on Linux. Later versions of .Net replace the original libraries for ones that work like Linux (99% at least). David Ashley On Mon, 2014-02-10 at 22:58 -0500, Michael Lueck wrote: > David Ashley wrote: > > 1. As always, the Windows implementation of IPv6 will cause us some > > pain. We really need to use the latest version of .Net > > > IPv6 within Windows does not have a native C/C++ interface, only .Net? > > Blessings, > |
From: Michael L. <ml...@lu...> - 2014-02-11 14:55:19
|
David Ashley wrote: > Later versions of .Net replace the > original libraries for ones that work like Linux (99% at least). (sssiiggghh...) That is a most unfortunate situation. So all of a sudden, to install ooRexx, ooRexx will be dragging along .Net onto target boxes. Bloat, bloat, bloat... So within .Net, MS did mapping between the native TCP/IP stack that comes with the Windows OS and publishes an API that is more similar to what Linux natively supplies? Aaaahhh... and Mono is an OSS/FS implementation of .Net... so perhaps ooRexx could harvest intellectual property from Mono, thereby bypass .Net as a dependency? Blessings, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ |
From: David A. <w.d...@gm...> - 2014-02-11 15:20:02
|
The problem is not with the APIs but with the way the libraries work underneath the APIs. The newer .Net replaces the underlying libraries. The situation may not be as bad as it sounds. I need to do more research to see what version of .Net we need and what versions were shipped with each OS and also what service packs updated. David Ashley On Tue, 2014-02-11 at 09:55 -0500, Michael Lueck wrote: > David Ashley wrote: > > Later versions of .Net replace the > > original libraries for ones that work like Linux (99% at least). > > > (sssiiggghh...) That is a most unfortunate situation. > > So all of a sudden, to install ooRexx, ooRexx will be dragging along .Net onto target boxes. Bloat, bloat, bloat... > > So within .Net, MS did mapping between the native TCP/IP stack that comes with the Windows OS and publishes an API that is more similar to what Linux natively supplies? > > Aaaahhh... and Mono is an OSS/FS implementation of .Net... so perhaps ooRexx could harvest intellectual property from Mono, thereby bypass .Net as a dependency? > > Blessings, > |
From: Mark M. <mie...@gm...> - 2014-02-11 15:32:09
|
On Tue, Feb 11, 2014 at 6:55 AM, Michael Lueck <ml...@lu...>wrote: > (sssiiggghh...) That is a most unfortunate situation. > Most people don't call this unfortunate, they call it progress. > > So all of a sudden, to install ooRexx, ooRexx will be dragging along .Net > onto target boxes. Bloat, bloat, bloat... > Most systems will already have .Net on them. So, nothing needs to be added. On the other hand, if you want to continue living in the previous millennium, you have no need of IPv6. There was no working IPv6 in the previous millennium. In addition, Rick is already concerned about people not being able to upgrade ooRexx because of a dependency on .Net that they don't want or need. Although we haven't hashed out the details on how to overcome that, since it is a concern, I'm sure we will arrive at some compromise there. But it will be a compromise that you will need to make. If you want and need IPv6, then you will need to use the software that supplies it. If you don't want it, then you will be able to use ooRexx, but you won't have IPv6. -- Mark Miesfeld |
From: Michael L. <ml...@lu...> - 2014-02-11 15:50:03
|
Greetings Mark, I am choosing to overlook your pointed jabs at my "Amish Computer Virus" ways. ( http://www.upperregister.com/~charlie/AmishVirus.html ) Mark Miesfeld wrote: > In addition, Rick is already concerned about people not being able to upgrade ooRexx because of a dependency on .Net that they don't want or need. That is the heart of my concern... seems I am not alone. More and more I work with Linux systems. Thus I was not aware that MS slipped into newer editions of Windows some level of .Net runtime. Maybe it is less of an issue than I perceived from my M$ insulated bliss in the Linux world. ;-) I use Linux like IBM promised I could use OS/2 back in 1992. Today Windows programs are confined to operating in a VM instance. I turn on the VM on an as-necessary basis. Mostly I leave it off and simply operate in the OS/3 world... uuummm eeerrr LINUX! ;-) Blessings, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ |
From: David A. <w.d...@gm...> - 2014-02-11 16:42:37
|
I have very mixed emotion about the current rxsock library. Let me just list some thoughts in no particular order. - The rxsock library is extremely complicated to use. You have to really know how sockets work in order to use it. There is not a high-level interface to it which is why I wrote rxsock.cls. - I think there might be a big difference between Windows and Linux users of rxsock, but I am not sure I can explain why. It is just a feeling I have. - Sockets are hard, and do not let anyone tell you differently. The rxsock library hides some of that complexity by just not allowing you access to it, like datagrams, udp, etc. You only get access to the TCP protocol from rxsock. - Although IPv4 and IPv6 use mostly the same APIs, there are differences in the data structures that are passed to those APIs. Thus it makes it harder for the users of rxsock to differentiate between IPv4 and IPv6 if the ooRexx function calls stay the same since we hide the data structures from the user. At this point I am leaning towards the creation of a class library for sockets to support IPv4 and IPv6. This would not replace the current rxsock library but would be made available for the ooRexx users to migrate to eventually. I think this could make sockets much easier to program. We could use the rxsock.cls as a starting point to figure out how it should be organized and what methods should be available. David Ashley |
From: Mike C. <mf...@sp...> - 2014-02-11 17:06:24
|
> I have very mixed emotion about the current rxsock library. > Let me just list some thoughts in no particular order. > > - The rxsock library is extremely complicated to use. You > have to really know how sockets work in order to use it. On the other hand, if you've already used sockets in (say) C, then it is a straightforward wrapper. So this might be more of a documentation issue (and changes from the way it works in C might steepen the learning curve). > There is not a high-level interface to it which is why I > wrote rxsock.cls. A high-level interface is good; fxftp.cls, for example, was a doddle to use when I had to convert from using the rxftp functions. The downside is when you need to set one of the obscure TCP/IP options (not necessary for FTP, in my experience) and it is not available in the higher-level model. > - I think there might be a big difference between Windows and > Linux users of rxsock, but I am not sure I can explain why. > It is just a feeling I have. > - Sockets are hard, and do not let anyone tell you > differently. The rxsock library hides some of that complexity > by just not allowing you access to it, like datagrams, udp, > etc. You only get access to the TCP protocol from rxsock. Not sure I follow .. UDP, etc., are not sockets, so they do not complicate sockets? > - Although IPv4 and IPv6 use mostly the same APIs, there are > differences in the data structures that are passed to those > APIs. Thus it makes it harder for the users of rxsock to > differentiate between IPv4 and IPv6 if the ooRexx function > calls stay the same since we hide the data structures from the user. Good point. > At this point I am leaning towards the creation of a class > library for sockets to support IPv4 and IPv6. This would not > replace the current rxsock library but would be made > available for the ooRexx users to migrate to eventually. I > think this could make sockets much easier to program. We > could use the rxsock.cls as a starting point to figure out > how it should be organized and what methods should be available. Maybe it should be task-oriented, and be higher-level than TCP/IP, even. TCP/IP and sockets are really quite low-level in the bigger (deeper, more complex) scheme of things. Mike |
From: Bill T. W. <wb...@ar...> - 2014-02-11 17:47:08
|
I realise that Sockets and TCP are directly related, and that UDP is not quite as related, would it be possible to provide for UDP, etc. type functionality, even if not implemented immediately? While I am not a C/C++ programmer, I have prototyped "Internet" based systems using ooRexx... I also like Mike's suggestion that the newer functions be more task oriented, but I'm not sure exactly how you would go about doing that. (I still think procedurally... <grin>) |
From: David A. <w.d...@gm...> - 2014-02-11 20:08:21
|
I have done some research and here is how IPv6 works out for Windows. Any version of Windows from Vista forward is fully compatible with the Linux APIs and functionality (with one minor exception easily handled in a common library, see below). Here are the requirements for a common library (Windows or Linux) which handles both IPv4 and IPv6. 1. IP addresses must be in IPv6 format when passed to/from the APIs. DNS names are handled by the internal APIs and converted to IPv6 format. 2. A Windows server socket must use the setsockopt API to set the IPV6_V6ONLY option to zero before binding the socket to an address. This option is zero by default on all OSs except Windows and BSD. So far these are all the OS requirements I have uncovered. If this holds, then I think we can create an IPvs library that can be used by all the Windows versions we currently support. Please note that does NOT include WindowsXP or Windows2000! The WindowsXP winsock library is NOT compatible with the Linux libraries and there is not really any support for IPv6 on Windows2000. So if we are in agreement I will start on the design for a common library that supports IPv4 and IPv6 which will be a part of a future ooRexx release. David Ashley |
From: Mark M. <mie...@gm...> - 2014-02-11 20:50:21
|
On Tue, Feb 11, 2014 at 12:08 PM, David Ashley <w.d...@gm...>wrote: > > Here are the requirements for a common library (Windows or Linux) which > handles both IPv4 and IPv6. > > ... > 2. A Windows server socket must use the setsockopt API to set the > IPV6_V6ONLY option to zero before binding the socket to an address. This > option is zero by default on all OSs except Windows and BSD. > My one suggestion is to do this internally, don't make the user do it. Just document that the default is 0, period. Then if a Windows user wants to change the default through setsockopt, she can. -- Mark Miesfeld |