Network Roadmap to Jnode 1.0?

As talk gears up for 0.2.6 release, and with the continued work in the java-net source branch, it's hard to know where to start or what to prioritize.

So, I'll just ask.

What is the roadmap for Jnode-Net from 0.2.6 to 1.0.0?
What parts of the net/ tree are everyone happy with for 1.0.0 release now?
What parts do people think need the most work?
What are the plans to merge the java-net branch into the trunk?

My thoughts are this:
Jnode-Net exists to provide services/interfaces/software for 4 distinct groups of "users":
* The OS itself, in the form of of discovering, configuring, controlling, securing, stopping network devices, protocols, and applications, (udpout, anyone?)
* The Jnode developers, in the form of abstracted APIs to write networking modules (for the entire stack) and applications on top of.
* Jnode system administrators, in the form of configuration, monitoring, troubleshooting, and reporting commands, as well as service daemons that provide network services (http server? nfs server?)
* Jnode users, in the form of an application suite that performs the network tasks a user wants (e-mail, instant messager, browser, rss reader)

For a roadmap, I would like to hear what everyone things the "feature set" for Jnode 1.0.0 should be, and my idea here is to discuss it layer by layer, as a set of "minimum" and "if possible" ideas, as well as "what we don't want", as a guide for where to best put effort.

Here are my ideas, as a straw man for everyone to start beating up.

Design criteria:
* 4 use-cases to consider - the OS itself, developer APIs, system administration, and end user.
* security over "traditionally there", the use-cases might also drive what security features are enabled or not?
* IPv4 first, IPv6 if possible without become a show-stopper.
* clients before servers
* design and document before coding
* Jnode as platform, not "everything and the kitchen sink" -- test application clients and servers for usability/compatibility with Jnode, but does it have to be included in the distribution too?

Application Layer Servers:
Minimum: none - is Jnode intended to be a server platform in 1.0?
If time allows: SSH suite (IPv4), NFS (seems already in production), HTTP (already in production?)
Not worth developing*: TELNET, FTP, R-services, XDM

Application Layer Clients:
Minimum: DNS (IPv4), DHCP (IPv4), NTP (IPv4), SSH suite (IPv4)
If time allows: DNS (v6), DHCP (IPv6), NTP (IPv6), RIP (IPv4/6), OSPF (IPv4/6), NFS (already in production?)

Transport Layer:
Minimum: TCPv4, UDPv4
If time allows: TCPv6, UDPv6

Network Layer:
Minimum: IPv4, ICMPv4, ARPv4
If time allows: IPv6, ICMPv6, ARPv6, IPsecv4, IPsecv6, IKE, InARPv4, InARPv6, RARPv4

DataLink Layer:
Minimum: 802.2/3 Ethernet station-to-station and broadcast, 802.11abg with WEP,WPA-PSK/WPA2-PSK, PPP
If time allows: 802.2/3 Ethernet multicast, L2TP, PPTP

Physical Layer
Minimum: 802.2/3 wired Ethernet LAN, 802.11abg wireless LAN
If time allows: USB, IEEE1394, Bluetooth, RS-232, modem

NIC drivers: can't have too many of these
WLAN drivers: can't have too many of these

* I wrote these as not-worth-developing because they are insecure, and not a very good idea on the 21st century Internet.
Unencrypted applications in general are a bad idea for a new OS to waste development resources on.
If someone wants these, it would be better to leave them as third-party add-ons, rather than endorsed, supported, shipped items.

Java.Net API todo list?

Java.Net support still needs (According to the report at):

Minor Nit To Pick:
* class SerialVersionUID=-3725819536092319830 in dk17, but SerialVersionUID=-2231209257930100533 in jnode

Missing Interface Implementations:
* class implements in jdk17, but doesn't implement in jnode
* class implements in jdk17, but doesn't implement in jnode
* class implements in jdk17, but doesn't implement in jnode

Missing Classes:
* class missing in jnode
* class missing in jnode
* class missing in jnode
* class missing in jnode

Missing Constructor:
* constructor missing in jnode

Missing Fields:
* field missing in jnode
* field missing in jnode

Missing Methods by Class:
* method missing in jnode
* method missing in jnode
* method,, int, java.lang.String, java.lang.String, java.lang.String,,$RequestorType): missing in jnode

* method missing in jnode
* method missing in jnode

* method missing in jnode
* method missing in jnode
* method, int, int): missing in jnode

* method missing in jnode

* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode
* method missing in jnode

* method, int, int): missing in jnode

* method, int, int): missing in jnode

* method, int, int): missing in jnode

* method missing in jnode

* method, missing in jnode

Correct me if I am wrong, but these are missing in Jnode's VM, ascompared to Classpath, OpenJDK, or IcedTea? I thought Jnode's VM incorporated the class library sources from those VMs? So where are they missing from?

And, I know a lot of the NetworkInterface stuff is in Jnode, but how to connect it up to support
Robert "Exile In Paradise" Murphey


That is a nice overview of the various protocols, utilities and applications on each level of the network stack that we should consider to implement.

You are talking about the JNode versions ranging from 0.2.6 to 1.0 but since we have roughly one month until the release of JNode v. 0.2.6 I would like to include this into the timeframe.

I think we should make the distinction between the networking features which are needed for and partly java.nio classes to be fully functional and the network applications which are built upon the standard and java.nio classes. The former together with the low level networking utilities and configuration tools mostly belong the the core of the JNode operating system while I would classify the later as part of the wider concept of a future JNode distribution.

At this moment I find it a bit far fetched to open a discussion about a JNode distribution and I would like to focus on the core networking services. In this context the most important features to be implemented are what you describe as minimum requirements starting from the physical layer up to the transport layer together with basic configuration and network diagnostic utilities that are necessary for setting up and testting those features. In fact those features are mostly implemented already, but they need various improvements in the domains operational stability and robustness, performance and various networking options defined in the package.

In the timeframe of version 0.2.6 I would like to see as many improvements as possible on the network (IPv4) and transport (TCP) layers of the network stack as well as in their corresponding configuration tools (ifconfig, route). In the subsequent releases I would like to see the above mentioned minimal requirements fulfilled in the sortest time whithin the limits of our hopefully increasing development capacity.

Beyond the minimal requirements support for IPv6 looks most important to me together with the next version of the protocols on the other layers that are required for it to be usable and interoperable with external IPv6 enabled hosts.

I completely agree with the idea, that network interface card driver development should be a constant hot topic for us all the time.

Beyond these features I don't have a strong opinion on priorities. Most probably I would analize the user feedback recieved in the meantime and establish a priority where most demanded features would be implemented first.

As a closing thought, I would like to let you know that we belive JNode could get a real world usecase in the shortest time as a paltform for small to middle sized server applications. Therefor we think good progess on networking has a capital importance. However we think that eventually JNode should become a flexible general purose operating system for executing Java code of all kinds. In the process of reaching that long term goal JNode as a platform for small to middle sized server applications is an important milestone.

Levente Sántha


So, if I read this correctly:
* The minimums I listed sound okay to start.
* The support for the API should be completed first.
* You would like the specific IPv4 and TCPv4 protocol support improved in the next month, but do not list what specifically you think needs to be improved.
* You think IPv6 is worth developing before Jnode 1.0.0.
* More network card support is always on the list.
* You don't want to talk about what should be supported in the 1.0.0 distribution, but think that distribution should support small to mid-level network server applications.
Robert "Exile In Paradise" Murphey



The NFS client is in production . The server it is not in JNode source , but i think exists an NFS server with GPL license and we can use it.

Best regards
Andrei Dore