Jython supports IPV6.
I am delighted to announce that jython is IPV6 ready: the future of internet addressing is fully supported.
IPV4 exhaustion
As you are no doubt aware by now (since it’s been covered in all mainstream media), the reign of Internet Protocol Version 4 (IPV4) is coming to an end: the IPV4 address space will run out before the end of 2011.
The problem is a simple one: IPV4 addresses are made up of only 32 bits, meaning that they can only represent a maximum of 232 different addresses (nearly 4.3 billion). But the internet is so successful and growing so fast that this address space is now too small: there are over 6 billion people on this planet, over 4 billion mobile phones, and over 1 billion PCs. Multi-device ownership is commonplace and growing in the rich world, and networking device ownership in the developing world is growing rapidly.
The decision to use 32-bit addresses was the right decision to make back in the 1960s. At the birth of the Internet, there were only several dozen machines connected to it. Rather than go into this subject in detail, I recommend reading this article: Vint Cerf on the Origins of 32-bit IP Addressing.
But as the Internet expanded and more and more machines connected to it, it became clear in the 1990s that IPV4 addresses would eventually run out, and that something would be needed to replace it: Internet Protocol Version 6 (IPV6) was born.
IPV6
IPV6 solves the address space problem permanently, by introducing a mind-bogglingly large address space: 128 bits, or 2128 possible addresses. That’s 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses! (Although see below for some caveats).
My favourite way to describe the size of this address space is as follows. If we were to divide the theoretical IPV6 address space between every star in the known universe (estimated to be 1022, or 10,000,000,000,000,000,000,000 stars), every star would have nearly 255 addresses to itself, i.e. an address space that is 8.4 million (223) times bigger than our existing IPV4 planetary internet (since 223 * 232 == 255).
That’s a lot of addresses, and once IPV6 is fully in service across the internet, we won’t be running out of addresses for a very long time.
(Actually, the number of addresses available under IPV6 will be less than the theoretical maximum, because various sub-sets of the IPV6 address space have been reserved for special purposes. But the set of addresses available will remain practically unlimited for the foreseeable future).
Java vs. python
As readers of this blog will be aware, jython is an implementation of the python language that runs on the java platform.
Both python and java have been moving towards IPV6 for a number of years. Both are multi-platform languages, and attempt to provide APIs that work seamlessly across all operating systems.
Cpython, the most well known version of the python language, that is written in C, first provided IPV6 facilities back in version 2.2, released in December 2001. This support, although complete in design, did not initially work on all platforms on which cpython is used, because underlying operating system support was variable and patchy.
Simiarly, java introduced IPV6 support in version 1.4, released in February 2002. But this support suffered the same problems as with cpython: underlying operating system support was variable, particularly on older OSes such as Windows 2000, XP and 2003.
Fortunately, most operating systems have caught up with the present, and provide excellent IPV6 support, including most open-source operating systems, MacOS and Windows since Windows Vista.
Jython and IPV6
As is always true when using jython, there are two different approaches one can take to using IPV6 on jython: 1. Use the Java socket API or 2. Use the python socket API.
The java socket API
Users of jython have always had access to IPV6 though the java socket API, because of the seamless integration between java and jython. However, jython users often avoid using java APIs, particularly the more over-complex ones. And the java socket API is probably one of the worst examples of over-complexity, since it comprises two entirely different APIs, with different designs, to provide the full range of socket functionality: the java.net APIs and the java.nio APIs.
The python socket API
Long term users of jython networking libraries, which rely on the socket module, will be aware that the jython socket module has a particularly difficult task implementing the python socket API, since it must implement the cpython API, which has a C language philosophy, on top of the java API facilities, which have a different, more object-oriented philosophy. And as described above, the java socket API is really two completely different APIs, both of which must be used if you want the full range of functionality, e.g. asynchronous networking.
Implementing IPV6 has been problematic, for several reasons, including that operating system support has been patchy, thus making it difficult to reliably test on a cross-platform basis. Also, the cpython socket API is not without problems when it comes to IPV6.
Still, it has always been my stated intent that any python code written which uses the socket module should behave identically on jython and cpython, wherever possible. And now that intent extends to IPV6, final support for which I checked in recently (revisions 7191 and 7193), and which should be included in the next release of jython, due any day now.
I am particularly satisfied with this step forward, since I believe that IPV6 opens up a whole new world of networking possibilities.
Reliability
I won’t yet make the claim that the new IPV6 support is 100% defect free, since there are so many different java-version and operating-system combinations on which jython is used. There will always be some combination of operations on some JVM on some operating systems where it just won’t work, for example this java IPV6 defect on Windows. But the jython socket module has a very large set of unit-tests, currently 133 separate tests, and growing. As and when bugs are uncovered, I will document them, provide work-arounds, and unit-tests for the work-arounds.
Happy IPV6 networking!