Roadshow 1.14 is out

[nogginthenog]

Does anyone run SMBFS in the user-startup? I'm getting a #80000008 software failure on boot.
I'm running a self-compiled 2.22 build from Olaf's github repo which has been rock solid for ages. I can transfer a 100MB LHA file without issues.

If I put an 8 second delay before SMBFS it's fine.
I'm not 100% sure it is due to this update.

Is user-startup is the wrong place to start SMBFS?

[Samurai_Crow]

Originally Posted by nogginthenog

Does anyone run SMBFS in the user-startup? I'm getting a #80000008 software failure on boot.

I'm running a self-compiled 2.22 build from Olaf's github repo which has been rock solid for ages. I can transfer a 100MB LHA file without issues.



If I put an 8 second delay before SMBFS it's fine.

I'm not 100% sure it is due to this update.



Is user-startup is the wrong place to start SMBFS?

If you're running the net start with a RUN >NIL it should be added to the end of the net start script.

[nogginthenog]

Originally Posted by Samurai_Crow

If you're running the net start with a RUN >NIL it should be added to the end of the net start script.

Thanks, that fixed it.

I've also moved my NTP clock update & synergy client there.

[flype]

Originally Posted by Olaf Barthel

Well, it wasn't planned that way, it just happened. Frustratingly, publishing AmigaOS 68k software became harder after the AmigaOS 3.9 release came to market, and it took a long time for the Roadshow 68k version to be published. This included numerous doomed attempts to build a graphical user interface for managing the slightly more numerous settings which Roadshow supports. I appreciate that "Roadie" exists, although looking at it, it makes me feel even more burned out about the failed attempts to make a user interface for Roadshow

Roadshow was the TCP/IP stack I wanted to use myself, which is why it's designed like it is (although not all the design decisions have aged well over the past 18 years).

A good part of what makes strange people such as myself keep working on Amiga software like Roadshow is to improve it, teach the old dog new tricks Amiga software development can be fun, even after all those 30+ years

@Olaf

i'd like know, please, if you allow that the RoadShow API (which is improved AmiTCP V4 +++) could be used by other stacks, such as discussed here :
https://eab.abime.net/showthread.php...20#post1431620

Your opinion is, to my eyes, fundamental before going in any further improvements.

[Olaf Barthel]

Originally Posted by flype

@Olaf

i'd like know, please, if you allow that the RoadShow API (which is improved AmiTCP V4 +++) could be used by other stacks, such as discussed here :
https://eab.abime.net/showthread.php...20#post1431620

Your opinion is, to my eyes, fundamental before going in any further improvements.

I have no objections and you have my blessings

Please note that the API designs I came up with have not necessarily aged well. This was a project which I started out of curiousity and I had nobody else to bounce my crazy ideas off during the early work which shaped everything that followed. So please use your own judgement on what is worth exploring and adopting. I would be happy to learn where there are faults in dearly in need of repairing or replacement.

Side-note: by European law you cannot claim copyright protection for an API design, so even if I had a good reason for even trying, it would not do. I am happy with what the law says and what it enables

[Olaf Barthel]

Originally Posted by Bruce Abbott

My only reason for using Roadshow is that it is about 5 times faster than AmiTCP at downloading files in IBrowse. That's quite an impressive speedup - can you tell us how you did it?

I reckon it's the combination of many small things adding up. Here is a small list off the top of my head:

Roadshow builds upon the 4.4BSD-Lite2 kernel code, and Unix kernels of that era tend to use interrupts for arbitration. For example, an inbound packet coming from an Ethernet device needs to be added to the inbound queue of the TCP/IP stack, and in a multitasking environment that requires arbitration so as not to mess up a different interrupt/process currently looking at that same queue. Higher level interrupts preclude lower level interrupts from occuring, allowing them to pick up after the higher level interrupt has completed. AmiTCP reproduced this arbitration system through the exec.library/Forbid mechanism in the kernel code and every arbitration is still in there and being used. In Roadshow I discovered that it's not really needed and you can use a single SignalSemaphore instead which is obtained/released when a system call is being made. This allows Amiga Task switching to take its natural course and won't unnecessarily impede all other Task by accident.

Memory management uses pools, which helps to keep memory fragmentation at bay and also avoids the use of Forbid/Permit when allocating and freeing memory. This, too, keeps Amiga Task switching in play at all times.

Roadshow supports the special SANA-IIR3, etc. send/receive commands which can transfer data in increments of 16 or 32 bits per word instead of just one byte at a time. This can make a noticeable difference.

Inbound and outbound data are received/processed/transmitted by means of I/O request queues of fixed sizes. If there's no room to receive more data, or to send data, then that data is simply dropped. Nothing clever about it, but it's a very fair system to schedule reception/transmission of data.

Memory is allocated for Roadshow's use under the assumption that it's probably a good idea to have large chunks available for sending/receiving full Ethernet frames at a time instead of breaking them down into fragments. Also, the controls of the TCP/IP stack are dialed in favour of Ethernet frames rather than in favour of the minimum IP datagram transmission size (576 bytes). Those 576 bytes used to be majorly important in 1994, but not today. By going for the bigger frame sizes, the TCP/IP stack has less work to do per byte transmitted

That's as much as I can remember right now.

[Olaf Barthel]

Originally Posted by Bruce Abbott

Interesting. I don't even use Gadtools in my GUIs, because I want them to be 1.3 compatible if possible.

That was in more than one way not an option for Roadshow which is designed to use everything which AmigaOS 2.x and 3.x provide to make it a better TCP/IP stack.

The issue with the GUI design was not how to build it from the GUI building block elements. It went deeper. Once Roadshow was working well enough, I spent several weeks over a design sketch which detailed which parts of Roadshow would be configurable, and how the GUI elements would work together to enable it. The end result was a specification of what was needed, how the individual settings would affect each other (if so) and how the user would make use of it.

Only when you've sketched your map and take a step back you'll notice how large the country is which it describes. By giving the user control over the configuration you empower her or him. This was the kind of GUI I would have liked to have, but I decided not to make it myself since I was still working on the TCP/IP stack and the API designs. Somebody else would have been more qualified than me to build that GUI from my spec.

This did happen for AmigaOS4, but it never came together for the AmigaOS 68k version.

For Roadshow I would have been satisfied with an installation script that asked for the basic network settings required (IP address, netmask, gateway etc.).

That's far from satisfying, isn't it? One of my goals in working out in the spec how the GUI should work was to perform validation on the settings as entered and providing hints and error messages if there were inconsistencies or errors in what was entered. Roadshow's own error reporting can never be as specific as a GUI which can show you exactly what needs fixing.

Having to hunt down the configuration files and manually edit them was a pain, and the documentation didn't do a good job of explaining what needed to be done.

Guilty as charged, your honour! This is the 3rd or 4th draft text, if I remember vaguely/correctly and my goal was to at least cover every single setting, dial and knob, and explain why it exists and what you might want to do with it. It's a reference manual but I lacked the time to gather feedback on its choice of matter and the quality of its information.

One of these days I hope to remedy its shortcomings, but it's hard

Then when I installed the commercial version it overwrote all my configuration files. Definitely not for beginners! Has this behavior changed in the latest version?

The current version should not do this. The Roadshow 1.14 installation script for the commercial version will check if you have the demonstration version installed and update only those components to the commercial version which need to be upgraded: bsdsocket.library and the PPP drivers.

If you rerun the same installation script after you have performed this upgrade it will give you a choice to uninstall Roadshow or make a backup of all its configuration files. In no event will it offer you the choice to overwrite your current installation.

[utri007]

When you a writing guide, less is more. 95% of us doesn't want to know why or what, they just wan't to get it work as fast as possible.

Wouldn't it be possible back port OS4 gui to OS3.X? I think that Chris Young has tinkered a lot with Reaction GUI. Maybe you two could help each other?

[Olaf Barthel]

Originally Posted by utri007

When you a writing guide, less is more. 95% of us doesn't want to know why or what, they just wan't to get it work as fast as possible.

Yes, definitely. A good pattern is to have a three-part documentation: 1) the introduction which gets you up to speed and shows you how to set things up (with notes on what can go wrong and how to remedy the situation), 2) the "cookbook" which collects "recipes" that show by example how to get various things done you'll invariably need to do at some point, 3) the reference which backs up the introduction and the cookbook with detailed information on what's what in excruciating detail (stress on "excrutiating").

I did not have the time to write and gather feedback on 1) and 2), and my hope was that by writing 3) somebody might be be able to work out how to build something resembling 1) or 2). Had I managed to write only either 1) or maybe 2) then all the detail in 3) would have been lost ("like tears in the rain"). And your average Amiga TCP/IP stack is possibly the strangest, most mysterious and supremely complex piece of software to set up and configure (e.g. try explaining IPv4 subnetting to somebody who you've checked for concealed weapons to do you harm if you fail to make your point). It would have been cruel to ship one without a detailed documentation.

I'm not happy to have written just the reference manual, but considering the options then, it may have been the best possible worst solution Or maybe the worst possible best solution.

Wouldn't it be possible back port OS4 gui to OS3.X? I think that Chris Young has tinkered a lot with Reaction GUI. Maybe you two could help each other?

It is not mine to backport. The intention was to share the workload of making Roadshow do its job and get better at it (the prolonged testing which Roadshow for AmigaOS4 received contributed to its feature set growing, and it becoming more robust and faster over the years). The OS4 GUI evolved in parallel with it, and I do not own it. That was a necessary trade-off.

[flype]

Originally Posted by Olaf Barthel

I have no objections and you have my blessings

Please note that the API designs I came up with have not necessarily aged well. This was a project which I started out of curiousity and I had nobody else to bounce my crazy ideas off during the early work which shaped everything that followed. So please use your own judgement on what is worth exploring and adopting. I would be happy to learn where there are faults in dearly in need of repairing or replacement.

Side-note: by European law you cannot claim copyright protection for an API design, so even if I had a good reason for even trying, it would not do. I am happy with what the law says and what it enables

Thank you Olaf, that's nice.

[utri007]

Originally Posted by Olaf Barthel

It is not mine to backport. The intention was to share the workload of making Roadshow do its job and get better at it (the prolonged testing which Roadshow for AmigaOS4 received contributed to its feature set growing, and it becoming more robust and faster over the years). The OS4 GUI evolved in parallel with it, and I do not own it. That was a necessary trade-off.

Even if there is no GUI, some kind of status window would b e nice? Something wich reminds that "I'm here" and "Click me if you want to know what is happening"

Basicly IP address and status online/offline. As bonus would be nice to if it could use to set Roadshow offline or online and if it could say status on current DNS and GW.

[pipper]

There is a tool “Roadie” that does this

[spudje]

Originally Posted by nogginthenog

Does anyone run SMBFS in the user-startup? I'm getting a #80000008 software failure on boot.
I'm running a self-compiled 2.22 build from Olaf's github repo which has been rock solid for ages. I can transfer a 100MB LHA file without issues.

If we're talking about GUI tools, sorry I know I'm going slightly off topic, I would love to see an updated SMB mounter or similar tool that supports that latest SMBFS.

[Olaf Barthel]

Originally Posted by utri007

Even if there is no GUI, some kind of status window would b e nice? Something wich reminds that "I'm here" and "Click me if you want to know what is happening"

Basicly IP address and status online/offline. As bonus would be nice to if it could use to set Roadshow offline or online and if it could say status on current DNS and GW.

Well, there's example code on how to do exactly that, and it ships as part of the free Roadshow SDK The complete source code of all the Roadshow shell commands is included.

Which is a roundabout way of saying: I already wrote all of this, and somebody could build just the tool you would like to see

[Olaf Barthel]

Originally Posted by spudje

If we're talking about GUI tools, sorry I know I'm going slightly off topic, I would love to see an updated SMB mounter or similar tool that supports that latest SMBFS.

Yes, this is somewhat off-topic but related in more than one way (smbfs being a networked file system client and that the same guy who came up with Roadshow also spent years on making smbfs work).

I reckon that the current state of smbfs needs a good hard look again because the level of complexity needed to cater for almost all wicked SMBv1/CIFS server implementations has already crossed the point of no return.

If you need a special tool to launch a different tool clearly something is not up to snuff. Could be that it has come to this because of the essentially broken and facepalmy nature of the SMBv1/CIFS protocol. This already stinks and perfectly covers any strong smell wafting out of the current smbfs implementation.

I'm not finished with smbfs yet (there are still unresolved Unicode shenanigans that need to be handled: I thought I had a robust solution for them in January this year and now look at where we are). And smbfs might not be finished with me either

[Daedalus]

Originally Posted by spudje

If we're talking about GUI tools, sorry I know I'm going slightly off topic, I would love to see an updated SMB mounter or similar tool that supports that latest SMBFS.

I've had an update of SMBMounter on my to-do list for a long time now, since there are lots of changes to SMBFS in the past couple of years that aren't supported. It's getting closer to the top of the pile now - maybe by the end of the year there'll be something to show for it on that front... But I can't promise anything