TCP/IP stack: A second great networking opportunity

since it uses it own Internet module?

The Internet module is a part of RISC OS (as of 3.6? 3.7? I forget – one was DCI2 IIRC).
I’m not familiar with VRPC, but if it’s supplying it’s own Internet module as an extension then, yeah, that’s going to be 26 bit isn’t it?

I thought there was a base issue with VRPC and RO5.

Just out of interest, does anybody know what? Doesn’t emulate the 32 bit world? ;-)

I thought there was a base issue with VRPC and RO5.

I had always presumed VRPC only worked with RO 4/6 but was disabused of that notion: https://www.riscosopen.org/forum/forums/5/topics/16563#posts-123785

Hmm, this is… puzzling. I had always assumed the difference between Internet 4 and Internet 5 was the former’s use of the DCI2 interface for talking to network drivers, and the latter’s DCI4. I hadn’t realised there was a difference in the socket API too.

First of all, it doesn’t seem beyond the bounds of possibility to write a compatibility layer converting COMPAT_INET4 SWIs to new ones. If it’s inconvenient to have that as part of the Internet module, have it as a separate module that rewrites the requests. It won’t be fast or efficient, but it should keep things working.

However a bigger question is IPv6 support. It’s no good having IPv6 support in the internet stack if applications don’t use it, especially if you’re on a network where you don’t have IPv4. That means things like doing DNS and getting both IPv4 and IPv6 addresses back, and then knowing how to connect to an IPv6 address.

You can’t really do that with a compat layer because you have things like apps expecting internet addresses to be 32 bits, which they aren’t any more. You could I suppose come up with some hacks (like using your COMPAT_INET4 layer to shim between IPv6 on the network and fake IPv4 addresses in the application) but it’s not very nice.

I suppose one way to look at it is this: RISC OS’ IP stack came into being in a dialup/telnet/Netscape/POP3 kind of world, and it’s now in a gigabit/TLS/Chrome/Office365 kind of world. The internet moves on, and the old applications (dialup, telnet, etc) aren’t much use these days. Even if we keep all the old apps running, the servers they talk to won’t be there any more. So, while breakage is an issue, the internet is going to break any unmaintained apps sooner or later anyway.

I don’t think IPv4 is going anywhere yet.

They’ve been predicting the end of IPv4 addresses for years now, and yet some major providers have only rolled IPv6 out in the last few years. Also, I don’t know about where you are but over here mobile comms are some weird kind of NAT using IPv4. Not to mention plenty of IoT widgets that can’t handle 5GHz, never mind IPv6.

Today? Adoption of IPv6 is still under 40%.
https://www.google.com/intl/en/ipv6/statistics.html

So the corpse of IPv4 will keep on kicking awhile yet.

I had always presumed VRPC only worked with RO 4/6 but was disabused of that notion: https://www.riscosopen.org/forum/forums/5/topics/16563#posts-123785

I think David P¹ was only soft loading on a base installation of RO4/6, but there was someone else that hacked/twiddled a little to get RO5 working as the base OS.

¹ I’m sure he will pop up with a description of what he had and had not done.

the old applications (dialup, telnet, etc) aren’t much use these days

Dial-up? Maybe not. ;-)

Telnet? Actually it and FTP get used here with local devices. As does ShareFS.

That said, it’s not so much the software keeping IPv4 around as the hardware. The IPcam is IPv4. The other one as well. Other bits and bobs.

As for IPv6, well it seems Orange doesn’t fully support ICMP or IPv6 only DNS. That’s according to online tests. My phone uses it when it can (such as to my site or Google), bit I’m guessing it’s reading the AAAA record from an old fashioned lookup. Which means…the corpse of IPv4 will keep on kicking awhile yet. ;)

Just out of interest, does anybody know what? Doesn’t emulate the 32 bit world? ;-)

I can give it a go (not earlier than tomorrow). My old copy of VA SA is locked again (probably due to Windows updates), so need to give Aron a call for the usual “unlocking mechanism”.

I remember however that VA could do 32bit on IOMD (so, if anything, only some bugs would break running RO 5 on it). VA indeed had a funky way to do networking, I remember NetSurf from 3.8 (maybe) stopped working (I did some investigation on that), and that was probably due the way cURL was being compiled or which SWIs it was using. So, yes, there might be something there that is not as we’d expect it to be.

In general, I would not recommend to use VA for “the future” of RO 5. Probably a better option (even above RPCEmu) is to work on QEMU and use Raspberry Pi 2 (or 1) as base for RO 5.

Not trying to argue with ROOL decisions, they must have their reasons for it, I just don’t see the point of keep supporting RiscPC with RO 5 when using RO 5 on a RiscPC makes it not particularly useful. So, to me, the only reason to insist supporting IOMD is because of RPCEmu and there it makes sense, unless someone comes up with a better emulation option.

At this time, considering the speed at which RO 5 has evolved over time, and using some pragmatism, it’s clear that the near future of RO 5 is in emulation and will be, at least, for a while. The issue is not just AArch64 being the new and only ARM architecture, the issue is also the big scarcity of old Pis (they are out of stock almost everywhere ATM, the only Pi relatively easy to find is the Pi 400). The next Pi is going to be (most likely) 64bit only. RPi OS has officially released the 64bit version, and the next chip may be only AArch64.

Sure, old RPis may appear back in stock again and so the might be still plenty of cheap platforms to run RO 5 natively, but at this moment this doesn’t seems to be the case.

For the comments ROOL made about ROD’s stack, I’d suggest to wait until we can have a look at both the sources. Not trying to pick sides, just trying to remember that RISC OS internally is a bit of a spaghetti architecture, so, any change could have big repercussions in a lot of places.

Also, just out of curiosity, did someone has tested ROD’s stack yet on an Iyonix/Rpi 1 or RPCEmu?

Not trying to argue with ROOL decisions, they must have their reasons for it,

IMHO, if you decide to allow a claim of a bounty worth over 11000 GBP that looks a lot like duplication of effort, communcation needs to be much better and much clearer than it has been to date. The discussion on Twitter just adds to the confusion and lacks any convincing facts.

But the situation wrt this bounty and its relation to the stack work ROD continues to do was always unclear, and both sides failed to communicate in a meaningful way. So why I expected a change here…I don’t know. Endless optimism?

I could be wrong here, but I think:

Internet 5 came with RISC OS 3.7. Perhaps a slight refresh from BSD developments at the time? Some API breakage, hence the compat flag.

Internet 4 was DCI 4. This was ‘release 2’ of the Protocol Suite. Shortly after, Acorn built it into RISC OS 3.6 and made the core !Internet application available freely. The stack was also embedded/licenced into things like the ANT Internet Suite.

Internet 2 (?) Was DCI 2. Part of ‘TCP/IP Protocol Suite’ package.

In parallel, Tom Hughes wrote his own stack: FreeNet. This was £200 cheaper than Acorn’s! There was an alpha DCI 4 version, but Acorn releasing theirs freely made it a bit pointless.

The DCI was, as its name suggests, only an issue for drivers. The applications (ArcWeb etc.) didn’t know or care about it.

So we have been here before with Internet stacks!!!

Must say, the communications from both sides have been pretty dreadful here. We may have a fork, or everything is absolutely fine. It is impossible to tell. Pretty spectacular how two positive stories can give an effect of foot-shooting, but that is RISC OS for you…

But the situation wrt this bounty and its relation to the stack work ROD continues to do was always unclear, and both sides failed to communicate in a meaningful way.

Must say, the communications from both sides have been pretty dreadful here. We may have a fork, or everything is absolutely fine. It is impossible to tell. Pretty spectacular how two positive stories can give an effect of foot-shooting, but that is RISC OS for you…

So why I expected a change here…I don’t know. Endless optimism?

Exactly, why, after so many years, do you expect a change? ;)

I could be cynical here and go with: Let them do their thing, don’t worry too much. If the result will be unsatisfactory then just remember all of this when both will ask for money, then you may have a say (eventually), and if not, then stop throwing money at something that refuses to do what a paying customer wants…

Pretty spectacular how two positive stories can give an effect of foot-shooting, but that is RISC OS for you…

Not disagreeing that it could be better presented but lets for a second split things down a bit:

Commercial development funded and aimed at a current commercial product portolio, that has a timescale to meet, does the work required to stay in business and then offers what it has done so far to the current source.

Open source team , who’s mission statement says “Safeguarding the past, present and future of RISC OS for everyone”, look at what has been made available and say thanks but we have to broaden it’s scope and who it benefits so we take what we can fropm the offer as it cuts down on the development time and now we only need to do x but we still have some constraints in changes made prior to 25yrs ago so lets start there.

The alternative could of been that the commercial funding offer is declined or timescales not agreeable so funding is not made available and no work done.

The commercial company losses the opportunity and we all wait on someone to start the bounty..

In an ideal world we have lots of developers who can put time in too do lots of work but we don’t so sometimes,like in the real world, we make a compromise that keeps the possibility open and fluid and then we are at least still in the game.

Now I accept that what I have written could just be laced with fairy dust but sometimes I’m not sure we have an idea of what some people in the RISCOS world have to do to keep our little OS going in the land of the living so perhaps we ought to give everyone involved a bit of slack and who knows Wakefield threatre talks may well provide all the clear answers :-)

My current interpretation is that ROD has made a new up to date network stack “because commercial reasons” which, for some reason, doesn’t target anything prior to ARMv7 ¹.

Meanwhile somebody in ROOL circles has decided that the way forward is… to make a new up to date network stack “because best for the community”.

I’m basing this on the news article which seems to be repeating what’s already been partially done, and a comment on Twitter that I cannot reproduce because the bloody thing is refusing to let me see more than a screenful without logging in or signing up.

It is like the 444 bus ². Nothing for ages, then two come along at once.

I just really hope I’m reading this wrong, as there are so many things that need attention to be taking the time and effort to do what somebody is already doing right now. It just doesn’t seem to make sense.

So, please tell me that I (and looking at it, various others) have misread this.

¹ I get that the development builds of the new stack may be compiled with ARMv7 options, but for integration into the codebase…uh…isn’t it written in C? If so, supporting “whatever” (even back to the RiscPC) ought to just be tweaks to the compiler flags to build an appropriate version?

² Reading-Yateley-Camberley (or was it Basingstoke?) back in the 80s.

The internet moves on, and the old applications (dialup, telnet, etc) aren’t much use these days.

And the mobile side even faster. Seems like they are starting to shutdown 3G in the States, which causes a problem with the older generations of connected objects.

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

VRPC’s Internet (and resolver) module just passes over RISC OS Internet 4 SWIs to the equivalent BSD style network calls on Windows, with some munging on the way in and out for where Windows got it wrong. At least that’s what my code for Red Squirrel did, before exactly the same functionality appeared in the commercial Virtual Acorn.

The stated aims of the latest step of the network bounty are long established and, following sterling fundraising from the RISC OS community, the work is now underway. Surely that’s good news? Exactly how that development pans out, as with all development, will be subject to change.

Commercially-driven development in the same area by a third party is also underway. That third-party works closely with ROOL, so there’s opportunity to feed some of that work back to ROOL. I suggest that’s potentially good news too.

Maybe things won’t work out but … let’s see!

@ Rick

I just really hope I’m reading this wrong, as there are so many things that need attention to be taking the time and effort to do what somebody is already doing right now. It just doesn’t seem to make sense.

We all are confused by this situation. Both the two network stacks should be written in C, so I too do not understand why ROD’s one wouldn’t work on v6, v5 and v4. However, in the other hand, until code is revealed, I suggest we do not take part and don’t try to judge or try to read between the lines.

Beside of everything, ROD still hasn’t commented on this decision, so we only have heard one side of the story and have no code to read and understand.

Again, I do think (or at least I hope) there is no malice. Surely there is extremely bad managed communication, but this is sadly a common situation.

Let’s see how the step 2 goes. In the end what matters is that the OS gets improved, and given that it’s no longer a main OS for all of us or an OS on which business and people careers depend upon, I think we can all wait and see.

We all are confused by this situation. Both the two network stacks should be written in C, so I too do not understand why ROD’s one wouldn’t work on v6, v5 and v4. However, in the other hand, until code is revealed, I suggest we do not take part and don’t try to judge or try to read between the lines.

Exactly, except from libsync style stuff, I don’t see what could prevent it to run on other platforms.

Regarding INIT4 compatibility, I had a quick look at the socket_swi source, most of the old SWIs remap to the new SWIs with a little bit of fiddling. The exception to this are sending and receiving which pass around an MSG_COMPAT flag to other functions in the file but I don’t think that it is passed to low level stuff. In other words I think there is no reason to break compatibility for old programs.

That said, I think it’s time that we as developers start looking for a little tutorial on how to make our applications IPV4/V6 compatible.

Shutdown 3G!

During the last Storm ‘U’ – the network dropped to to E+ here.

32bitted Internet and Resolver Arm Assembly code modules – found RO 5 Resolver worked Ok so only Internet required.

I use a 32bit RSq HostFS.

I could be cynical here and go with: Let them do their thing, don’t worry too much. If the result will be unsatisfactory then just remember all of this when both will ask for money, then you may have a say (eventually), and if not, then stop throwing money at something that refuses to do what a paying customer wants…

You are of course absolutely right, and I have now cancelled my monthly payment to ROOL (running for 8 years now according to PayPal) until a satisfactory explanation is forthcoming.

We all are confused by this situation.

until a satisfactory explanation is forthcoming.

And the broken cog award of 2022 goes to…. 😂

32bitted Internet and Resolver Arm Assembly code modules

I guess a problem would be permissions to distribute an updated Internet for VRPC though?

I guess a problem would be permissions to distribute an updated Internet for VRPC though?

Wasn’t that part of the logic behind patch utilities?

32bitted Internet and Resolver Arm Assembly code modules

They’re written in C, so I’m guessing you meant you did the conversion with a disassembly of them…
…if so, there could be some interest in a write-up of how you did that, as switching from 26 bit C to 32 bit at binary level is “non-trivial”.

You mean like in the !ARMalyser Docs.C32ModuleTemplate/s file?