TCP/IP stack: A second great networking opportunity

I originally read the announcement as a good thing for RISC OS and the community. A second reading raised the following questions:-

Are we heading back to a Castle versus ROL situation? Or have I misread the announcement or misheard something. I understood that ROD had been Beta testing a new TCP/IP stack. Now, ROOL has authorised the spending of bounty funds for their stack? Why the apparent divergence?

I expect both sides to work together and spend the bounty contributions wisely on integration. Or is one or both sides in the realm of ego and petty politics? Or is there another reason?

It is a rather peculiar announcement given that some of us have been testing a new stack recently.

I don’t think it’s to do with ego and petty politics – we’ve already been through that and the fallout lasted decades. :-/

I am not privy to any specific information, but something that stands out to me is the phrase “commercial use in a specific vertical market” as well as the references to the RiscPC. It may be, and this is just conjecture, that the current new/IPv6 stack is for the specific devices related to whatever that commercial work is, with ROOLs work to enhance that and provide support for everything else.

It’s a peculiar announcement, but let’s wait for some clarification rather than assuming malice.

let’s wait for some clarification rather than assuming malice.

Indeed lets not go down the RISCOS wars front again where some, in my view, drove discord for their own means/reasons.

Recent ROD communications imply that relations are good with ROOL and they meet regularly and indeed some of the work being done has seen it’s way in back to ROOL.

Speculating on what Rick says then also don’t forget there is an lot of additional work getting something aligned to ROOL’s setup, also UI/Configuration setup and providing documentation etc and that needs to be considered.

Hopefully all building up nicely to some additional bits to be made available as part of the ROOL beta builds for more wider testing.

So lets just see this as a another positive step.

No malice assumed here but reflecting on what I wrote, I get how we reached that viewpoint, as Rick said, “a rather peculiar announcement”.

No malice assumed here

At least us three are clear then :-)

Think Rick is on the right track on the wording of “vertical markets” and mentioning of RISCPC in the ROOL bounty announcement.

Well, I’d say that the prime thing general users should be looking at is this bit:

Developers should note the old Internet 4 (pre-1996) support is scheduled for removal during these works. This affects around twenty components in RISC OS itself, these will be migrated to Internet 5 over the coming weeks such that support can be phased out of the existing sources in the first quarter of 2022.

For developers, the focus might be more on:

Existing applications will continue to run on the current stable release, RISC OS 5.28 but will need to make sure they’re using the Internet 5 calls ahead of RISC OS 5.30, which is slated for release later in 2022. Watch out for more details on how to rebuild your code if you’ve been using the COMPAT_INET4 option.

As to the element Rick focussed on:

something that stands out to me is the phrase “commercial use in a specific vertical market”

IIRC Andrew R. mentioned that commercial item some while back, and pointed out that that alone brought a significant amount of funding.

I have no idea if this announcement is good news or bad news. Which makes one thing clear: it is at least bad communication. The paragraüh about “the other stack in development” is phrased in a complex, non-understandable and unclear way. I can only assume this was done for some reasons, but I have no idea which reasons. Clear communication about the ROD stack development while keeping the bounty open was missing for probably the past two years, so that new announcement comes in a long tradition of miscommunication concerning the network stack topic.

The comment about the IOMD platform being the second-most used is also interesting – how was this determined? Educated guess? And why is this relevant? It is not explained anywhere in the announcement, just maybe slightly hinted at.

I wonder if it might be an uncomfortably short time to rebuild lots of network apps, if the interface we’ve been using for decades is going to be suddenly removed.

I wonder how much code will cease to run because it’s no longer supported and therefore will not be ported to the new interface.

I’m not sure that I agree with “suddenly removed” when it’s been stated in the bounty text for more than three years. However, I do admit that not everybody reads the bounties.

Surely mention of the Risc PC is a bit silly – what are these guys on? Obsolete hardware that noone uses any more.

I think there is quite a lot of RPCEmu use!

My use of “sudden” refers to the time between the new stack first becoming available and the old one becoming unavailable.

I used to think why not just drop IOMD builds until I read that RPCEmu relies on it. I don’t know how much of a drain keeping IOMD builds is, but wonder could there be IyonixEmu or jump a generation and have a PiEmu?

My use of “sudden” refers to the time between the new stack first becoming available and the old one becoming unavailable.

If I understand correctly, any apps using the current (Internet 5) stack will continue to work. It’s only apps using Internet 4 that need to be updated.

The GitLab history indicates that Internet 5 has been around since the 90s. So, 25 years is “sudden”? :)

I’ll try and summarise the situation regarding Internet 4 support / COMPAT_INET4. Bear in mind that I’m not involved in the bounty, so this is just based on my reading of the current OS sources.

• The Internet module provides two sets of Socket_ SWIs. There’s the old Internet 4 set (Socket_Accept, etc.), and the new Internet 5 set (Socket_Accept_1). If you’ve heard of Socket_Accept but not Socket_Accept_1 then that’s probably not surprising, considering that even the most recent version of the StrongHelp “Internet calls” manual (InetSocket 1.07, from 2018, from riscos.info) doesn’t make any mention of the new SWIs.
• The Internet SWIs are designed to map directly to the BSD socket syscalls. It looks like the main difference between the old and new APIs is the layout of the various structs used.
• In the OS sources, and shipped with the DDE, is a set of libraries called TCPIPLibs. One of these libraries is the socket library, which provides a BSD-compatible, C-friendly socket API which calls the underlying Socket_ SWIs. It’s this library which provides the COMPAT_INET4 option, to control whether the API exposed by the library is (primarily) the old API or the new one. I say “primarily” because (as I understand it) the library actually allows you to use all three at once, the only difference is in whether the default interface is the old or the new ones. E.g. oaccept() is always Socket_Accept, naccept() is always Socket_Accept_1, and COMPAT_INET4 controls whether accept() is Socket_Accept or Socket_Accept_1.

Is COMPAT_INET4 going away? Yes. This will affect anyone who’s maintaining code which uses TCPIPLibs and has to recompile it with a newer version (especially since the TCPIPLibs documentation says “Typically, most programs will be compiled with COMPAT_INET4 enabled”, implying that it’s recommended to use that option).

Are the old Socket_ SWIs going away? That’s unclear. I can’t see anything obvious in the Internet module sources to suggest that they’ll go away. There is a COMPAT_OLDSOCK option which controls whether the old SWIs are supported, but (a) it looks like the module will fail to build if you try turning off that option, and (b) the glue for mapping the old SWIs to the internal interface is all contained in one C file, so it shouldn’t be an inordinate amount of work to continue to support the old SWIs, at least in a limited form.

The TCPIPLibs documentation gives more detail on COMPAT_INET4 and the old vs. new SWIs: https://gitlab.riscosopen.org/RiscOS/Sources/Lib/TCPIPLibs/-/blob/master/LibraryDoc

A quick look at GCC’s UnixLib sources suggests that it’s been exclusively using the new Socket SWIs since at least 2010 – anyone using an older version of GCC can dig through the history themselves to work out when it was switched over.

For everyone else (i.e. those who have written code which uses the Socket SWIs directly), it wouldn’t surprise me if they were using the old SWIs, simply because the StrongHelp manuals have made no mention of the new SWIs.

Thank you for your explanation, Jeffrey.

For everyone else (i.e. those who have written code which uses the Socket SWIs directly), it wouldn’t surprise me if they were using the old SWIs, simply because the StrongHelp manuals have made no mention of the new SWIs.

I’m one of the “everyone else”, because I’ve been using the paper PRM5a. I hadn’t heard of any update, addition or change as you describe.

Come to think of it, where do we get the documentation to start using the 25-year-old new stuff now?

The new SWIs are documented (briefly) towards the bottom of the TCPIPLibs LibraryDoc: https://gitlab.riscosopen.org/RiscOS/Sources/Lib/TCPIPLibs/-/blob/master/LibraryDoc#L2289

I’m one of the “everyone else”, because I’ve been using the paper PRM5a. I hadn’t heard of any update, addition or change as you describe.

I am the same. I write in BASIC.

Normally, I expect ‘everone else’ to be the larger sub set. Is that not the case?

I am confused.

Communication is, I agree, poor.

What applications will stop working? Netsurf? Messenger? Hermes? Netfetch? The ‘geo:’ protocol? Will network configuration change in any way? What about !Ftpc?

What applications will stop working? Netsurf?

NetSurf should be using cURL, so most likely won’t break.

BTW, ROOL gave some explanation on twitter tonight, read the whole discussion:

https://twitter.com/risc_os/status/1494718264869597184

Opinions are divergents, however ROOL said they will do they best to keep the two stacks compatible, but clearly this may open a case for a fork. Let’s see how this will work out, hopefully ROD will not go out with their RISC OS fork using another stack.

The GitLab history indicates that Internet 5 has been around since the 90s. So, 25 years is “sudden”? :)

Indeed.

Given the importance of the Internet, and how few developers we have, there is no justification for breaking existing applications (indeed, the ROD stack shows that it can be done).

What may happen is that the changes break the ability to compile existing applications, because stuff in the headers change. Which isn’t great, but is less damaging. Although, again, given the current new stack is a drop in replacement, I’d seriously question any breakage.

As such, I strongly disagree with the assertion (on Twitter) that:

Because their approach breaks lots of existing RISC OS software

I’m running a test version of the new stack. Nothing has broken. Sure enough, it’ll all be IPv4 only, but it works.

Plus, how can they be accused of breaking things, when this discussion seems to relate to the amount of things the second (?!) stack may end up breaking?

Given their ARMv7 cutoff, would it not make more sense to support the ROD stack inasmuch as getting it working on the older machines, rather than creating an entirely different stack?

Because, I don’t want to be a naysayer here, but given the issues raised by the inability to correctly handle version numbers with one module and some behind-the-scenes brokenness (hello AcornHTTP), I can’t help but think that developers trying to juggle the quirks and level of support of two different stacks could turn out to be a nightmare.

And, I’ll repeat again, the test version of the new stack does not appear to have broken anything. My server uses low level socket code. WedJames still works. As does Manga, NetSurf, blah blah blah.
The only thing that ‘broke’ was ping because the test version had something hard wired (DNS server?) and my setup was different. It’s a known and acknowledged issue.

I wonder how many C programmers here read enough of the TCLib docs to know about the COMPAT_INET4 define?
I guess 99% of the 32-bit compatible programs use the default settings, that is to say use the Internet5 variant.

The only other case would be using the SWI calls directly but then again how many would use the SWI calls
instead of using the TCPLib library since it make it portable to/from other platforms.

Does this effect VRPc – since it uses it own Internet module?

Does this effect VRPc – since it uses it own Internet module?

I thought there was a base issue with VRPC and RO5.
How many people have managed to get VRPC running RO5?