Best TCP Software

[olsen]

Yeah, but look at Roadshow, it took like 10 years for him to "wrap it up" and get it out.

I would have preferred to have Roadshow available much earlier (say 2001-2002), but then the whole Amiga market took a dive, along with all the companies which I had been doing business with before. I won't go into the cruel details of trying to get a GUI developed for Roadshow...

On the positive side, the "slight delay" allowed for Roadshow to mature.

And he has other projects too, like CygnusEd. And Term, hehe. And gtlayout.library. At least there are some sources for those available, though perhaps not the latest.

Other projects not listed here take up a lot of time, too

[olsen]

I recently installed RoadShow demo, and boy was it intrusive! It only left som documents in the drawer I appointed it to, and installed everything all over sys: :eek:

I mean - assigns, path - why not use them!

Because Roadshow was intended to ship as part of the next AmigaOS update, say 2001-2002. It is a part of AmigaOS4. I did not want to go the same route as AmiTCP or Miami. The TCP/IP stack should be integrated into the operating system and become practically invisible.

The default installation puts Roadshow on the boot partition, along with a short script which is called from "S:User-Startup". But, as these things are, you can put the Roadshow components wherever you believe they should go. There are no hard-coded paths, except for the icon default tools.

Also, I did my best to make the Roadshow installer script not only put the files where they are, you can also uninstall all of them again with the installer. The only thing that is not as easily uninstalled is the addition to the S:User-Startup script.

[olsen]

Support? Has Olsen given any signs that he intends to support it further?

Yes, I have. Repeating it here

That said, I have been working on an update for a while which I have not yet released. It's mostly small bug fixes for now. Because my A600HD test machine croaked I will have to test the recent changes to Roadshow on WinUAE, I suppose

Question is if "winuaenet.device" works on a plain emulated 68000 system. If I remember correctly, "a2065.device" does not work on a plain 68000 system, so I cannot go the route of having WinUAE emulate the hardware.

[olsen]

Somebody get this man a classic system, stat!  

I have a good number of 68k machines at home in working condition. The only machine which is not easily replaced is the plain 68000 test hardware which I used for Roadshow benchmarking and compatibility testing: the A600HD. I have two A500+ machines in the attic, but none of these can be easily made to use networking hardware suitable for Roadshow testing.

As I just learned, the A600HD may have suffered from "SMD capacitor decay". I gave up my soldering gear for good more than a decade ago, but it looks like I might have to look for it again in the attic. Apparently, you can replace the capacitors, but you'd still have to know why the A600HD stopped working. It may not be the capacitors which are to blame.

[olsen]

Everybody likes to point out that Miami is slow, nobody care to ask why. Holger wanted to bring networking on Amiga further, he even had a bit of a plan on how to do this, optimizing for sana2 was not his focus, sana2 falls short quickly in modern scenaries, so he developed MNI as a suggestion as a path forward. However, his dreadfully slow tcp-stack that noone really should want to use, was heavily pirated. And he, like so many with him, thought of Amiga as a "market" rather than what it is, so he got delusioned and angry, and left Miami behind. Miami could have been awesome, it could have been the standard TCP stack for Amiga. But no, because, delusions.

My pet theory as to why Miami's throughput does not compare favourably with other Amiga TCP/IP stacks is that Holger ended up leveraging the existing NetBSD kernel drivers, and this did not turn out as well as he had hoped.

From my own experiments, dialing up the number of I/O queue entries for the SANA-II drivers correlates with throughput increasing. The SANA-II model seems to match how the Amiga operating system wants I/O to be done better than what the NetBSD model can do under the same circumstances.

In theory, with MNI drivers interacting with the TCP/IP stack without having to go through another layer of copying data around should be the right thing, as it eliminates at least one step of copying between the network hardware and the kernel input/output queues.

In practice the MNI drivers are faster than the SANA-II drivers, when used in Miami. But both AmiTCP and Roadshow can be made to run faster still, using exactly the same SANA-II drivers which run more slowly on Miam, by increasing the number of IORequests in the receive/transmit queues.

[olsen]

But on any platform you would use Roadshow 68k on, it clearly is not part of the OS, and that much is obvious! The least you could do is to give the user options, to carpet bomb sys: with files and directories, or a more conservative approach.

I'll make a note on the TODO list. The installation script would need to be modified, but this isn't exactly rocket science.

The documentation which ships with the installation archive already contains notes on what you need in order to customize the installation, i.e. which files are essential and where they go. You could use that as a basic guideline for rolling your own setup script.

Noone expect that to work, hehe.

Nobody expects Installer scripts to be useful beyond slapping the contents of a product onto your hard disk. I have seen Installer scripts which are a very thin wrapper around unpacking an .lha archive.

The Roadshow Installer script is old-fashioned and complex. It even allows you to run it in "pretend" mode and create a report of what it is doing before you might want to install the software for real.

[olsen]

Up to now I never understood the advantage of having the TCP/IP stack integrated into the OS.

You don't believe that would make the AmigaOS more secure, do you?

No, this is not a security issue. If somebody wanted to make trouble, then there are easier ways to achieve this than through the TCP/IP stack.

My idea with Roadshow was that you should not need to launch the TCP/IP stack manually or through the Workbench. Starting it as part of the S:Startup-Sequence or S:User-Startup should take care of that. However, if you start AmiTCP or Miami from the S:User-Startup file they will open splash windows which force the Workbench screen open, and that isn't always helpful.

If you choose so, Roadshow starts quietly as part of the normal system startup (through S:User-Startup) and will not open a window or complain unless there is something to complain about. This is what I mean by "invisible": no idle chatter, no fireworks, etc.  You should notice the TCP/IP stack only if something didn't work right.

That said, launching Roadshow from S:User-Startup has its drawbacks. If something goes wrong, you probably won't see the error or warning message  Error reporting from inside the S:User-Startup script (or for that matter, the S:Startup-Sequence) is fundamentally broken.

[olsen]

It's been a while since I started Miami through User-Startup (I normally use WBStartup), but the way I have it configured now the only thing it opens on Workbench is the appicon, so I can quickly access its settings or go online/offline easily (e.g., for some games that don't like having a TCP/IP stack running in the background).

TL;DR.  You can disable the splash screen through settings.  

Had I known that in the year 1999 then I might not have been quite so keen to start working on Roadshow  That splash window was so annoying...