English Amiga Board


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 13 May 2019, 12:50   #1
stevelord
Registered User

 
Join Date: Apr 2019
Location: UK
Posts: 62
Roadshow vs AmiTCP/GENESiS

Hi,


I have GENESiS from OS3.9 working with a Serial/PPP connection in my A4000 while I wait for the MNT ZZ9000 (which will be SANA-II).


I'm aware of the CPU overheads with using serial.device, but I was wondering if anyone's done any testing of GENSiS/AmiTCP vs Roadshow. Are there any compelling reasons to choose roadshow over AmiTCP if AmiTCP is working?
stevelord is offline  
Old 13 May 2019, 21:00   #2
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 796
For me the compelling reason to use Roadshow is that Olaf still develops and supports it!
You can try a replacement serial device. I seem to remember 8n1.device works well.
nogginthenog is offline  
Old 20 May 2019, 23:59   #3
Sir_Lucas
Registered User

Sir_Lucas's Avatar
 
Join Date: Dec 2008
Location: Norwich, UK
Posts: 643
It's the same for me if it comes to Roadshow. The fact that it is still developed is a very important factor.
It supports DHCP and it's a bit faster than AmiTCP.
Roadshow is also a lot easier to configure.
Sir_Lucas is offline  
Old 30 May 2019, 18:01   #4
gdonner
Ancient Amiga User

gdonner's Avatar
 
Join Date: Mar 2018
Location: Elkhart / United States
Posts: 47
Like nogginthenog and Sir_Lucas noted, it's newer, and has more up-to-date support for current Internet protocols, etc.

It also works very well, and is very efficient.

My only real wish for Roadshow (besides wanting it to have a long, well-updated life) is that it would have a small, but handy GUI for tweaking the few config items that need to be adjusted after installation.

Otherwise, it's very good, and well-worth the money.

One thing I've learned is that, starting with his 100%-Style Guide compliant "Term" program back in the early 90s, Olaf Barthel writes reliable, quality software.
gdonner is offline  
Old 01 June 2019, 17:52   #5
indigolemon
Bit Copying Bard

indigolemon's Avatar
 
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 36
Posts: 719
Quote:
Originally Posted by gdonner View Post
My only real wish for Roadshow (besides wanting it to have a long, well-updated life) is that it would have a small, but handy GUI for tweaking the few config items that need to be adjusted after installation
It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

On Aminet here:http://aminet.net/package/comm/net/Roadie

Some screenshots:


The Main Window


Showing results of the ShowNetStatus command


Editing an Interface file

Last edited by indigolemon; 05 June 2019 at 19:18. Reason: Added aminet link and screenshots
indigolemon is offline  
Old 01 June 2019, 23:37   #6
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 879
Quote:
Originally Posted by stevelord View Post
Hi,


I have GENESiS from OS3.9 working with a Serial/PPP connection in my A4000 while I wait for the MNT ZZ9000 (which will be SANA-II).


I'm aware of the CPU overheads with using serial.device, but I was wondering if anyone's done any testing of GENSiS/AmiTCP vs Roadshow. Are there any compelling reasons to choose roadshow over AmiTCP if AmiTCP is working?
I bought Roadshow but decided not to use it. Two reasons, I not happy how well DHCP client works and it doesn't have a GUI. So instead of manually configuring IP, I reverted back to Genesis.

I'm not regretting to buying Roadshow, I might found use for it latter.
utri007 is offline  
Old 03 June 2019, 16:03   #7
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by nogginthenog View Post
For me the compelling reason to use Roadshow is that Olaf still develops and supports it!
I am definitely working on it, but it's taking longer than I had expected to get the overdue update out the door

Summer's coming up, and there's one thing I learned during that long hot Summer of 2018: even if the heat is getting me down, I can still crank out perfectly working Amiga code and debug it, too. Just don't ask me how this works, it just does

So there's hope that I'll be getting the update ready this year.
Olaf Barthel is offline  
Old 03 June 2019, 16:04   #8
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by utri007 View Post
I bought Roadshow but decided not to use it. Two reasons, I not happy how well DHCP client works and it doesn't have a GUI.
What can I do to make the DHCP client work better for you?
Olaf Barthel is offline  
Old 04 June 2019, 13:42   #9
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,084
Quote:
Originally Posted by Olaf Barthel View Post
What can I do to make the DHCP client work better for you?
Disable it, apparently If Genesis works better with DHCP then there's something really strange going on with his network.
Daedalus is offline  
Old 05 June 2019, 10:40   #10
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by Daedalus View Post
Disable it, apparently If Genesis works better with DHCP then there's something really strange going on with his network.
Either that, or limitations of the built-in Roadshow DHCP client make themselves felt.

Due to an oversight of mine the built-in DHCP client can only negotiate a lease extension but it cannot rerun the entire IPv4 address acquisition process. This should rarely be a problem, but if it is, you don't get a hint from Roadshow that you will need to use the ConfigureNetInterface command to get going again.

I need to fix this, but in the past few years I could not come up with a satisfying solution

The DHCP negotiation can fail, too (for various reasons). In order to diagnose the problem you need to be aware that the negotiation failed, then enable debug mode for the network interface in question and retry. Roadshow will open its debug console window and print progress (and failure) messages while it's trying to make the DHCP negotiation work. None of this in any way near obvious and reading the manual should not be a requirement for diagnosing network problems. Still, it's hard to make this sort of thing work well for both the user and the developer.

As to why DHCP negotiation may fail, there's a great variety of possible causes, ranging from hardware trouble (flaky cabling and connectors) to routing problems, to multiple "authoritative" DHCP servers fighting it out in the network, to DHCP servers running out of leases (to name a few of the less bizarre causes). There's very little joy in finding the cause of the problem, especially if the DHCP client fails to produce helpful debug output.

So I guess it's fair to ask what could be improved in order to solve the problem which utri007 mentioned.
Olaf Barthel is offline  
Old 05 June 2019, 12:09   #11
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,084
Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.
Daedalus is offline  
Old 05 June 2019, 12:20   #12
spudje
Registered User

 
Join Date: Dec 2014
Location: Netherlands
Posts: 971
Quote:
Originally Posted by indigolemon View Post
It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

http://www.indigolemon.co.uk/linkedi.../Roadie1.0.lha
Sounds cool! Any screenshots before I consider trying?
spudje is offline  
Old 05 June 2019, 13:47   #13
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by Daedalus View Post
Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.
One you can depend upon (it never works), the other you cannot (it may not work as intended, but it's hard to predict under which circumstances). Sort of like the old saying that a stopped mechanical clock accurately tells the time twice a day whereas a working mechanical clock is never accurate
Olaf Barthel is offline  
Old 05 June 2019, 19:18   #14
indigolemon
Bit Copying Bard

indigolemon's Avatar
 
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 36
Posts: 719
Quote:
Originally Posted by spudje View Post
Sounds cool! Any screenshots before I consider trying?
Have amended my post above
indigolemon is offline  
Old 08 June 2019, 01:34   #15
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 879
Quote:
Originally Posted by Daedalus View Post
Ah yeah, that's fair enough. No software of that magnitude is perfect (and I have the greatest of respect for your work, and your passion to improve it), I was just wondering how a 0% working DHCP client was better than a 97% working DHCP client.
Setting static IP with GUI is better than doing it with text editor.

Some times it fails to get IP and some times it negotiate a long time. It doesn't tell when it is online.


Problem is also in a AOS4, but that version of Roadshow has a GUI.
utri007 is offline  
Old 10 June 2019, 11:51   #16
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by utri007 View Post
Setting static IP with GUI is better than doing it with text editor.
I totally agree to that. For example, the GUI can validate the IP address entered and refuse to accept invalid/unsuitable input (explaining why it is invalid/unsuitable). By the time Roadshow gets to look at the configuration file it cannot do much more than reject such input, which is made worse by the fact that during system startup it's difficult to even show an error message

Early input validation is crucial. While the Roadshow documentation states that familiarity with setting up the network configuration is required, I doubt that those users who run into difficulties will find this notion helpful, to say the least (who reads documentation anyway?).

Quote:
Some times it fails to get IP and some times it negotiate a long time. It doesn't tell when it is online.
Again, this is a problem born out of how/when the interface address acquisition occurs It could be mitigated by moving this particular task to a later stage when the Workbench is already open and error messages are easier to display and to record.

Almost 19 years in, I haven't come up with a decent solution to this problem, which is in part caused by design decisions which sidelined error handling and reporting. AmigaOS lacks an error logging and reporting mechanism, which affects the entire early system startup process (with the boot shell executing the S:Startup-Sequence script). If anything goes wrong during S:Startup-Sequence execution it's very hard to figure out what happened, and it's worse for S:User-Startup execution which is likely to be immediately followed by LoadWB and EndShell: the boot shell window closes instantly after it has briefly shown any error messages.

If you want to have another look at the DHCP client doing its job and not getting anywhere fast, or failing, I would recommend editing the interface configuration file, changing the line #debug=yes to debug=yes, entering NetShutdown followed by AddNetInterface <name of your network interface>. That should cause Roadshow to start over, open a debug output window and display every step of the DHCP process. If the DHCP process fails for you, the debug output might help in tracking down the cause of the problem.

The DHCP negotiation takes a bit longer (60 seconds) because the client verifies that the IPv4 addresses it was offered are not currently in use. Thus, a timeout has to occur before Roadshow accepts it. You can change that timeout with the TIMEOUT parameter or icon tool type. The minimum are 10 seconds. Yikes, I seem to have (as usual) overengineered this one, neglecting the usability of the interface setup

Quote:
Problem is also in a AOS4, but that version of Roadshow has a GUI.
Neither the AmigaOS4 nor the 68k version of Roadshow show the DHCP debug output by default, and the interface timeout (unless overridden) is set to 60 seconds, too...

Last edited by Olaf Barthel; 10 June 2019 at 12:07.
Olaf Barthel is offline  
Old 10 June 2019, 20:50   #17
duga
Registered User
 
Join Date: Nov 2010
Location: Sweden
Posts: 371
Quote:
Originally Posted by indigolemon View Post
It's my first attempt at writing software for the Amiga, but I've just finished a little commodity I'm calling Roadie if you want to give it a spin? I need more people to test it

Needs KS2.0+ and an 020+ (I really do need to work what I've done to make it need an 020!) - apart from that it should be self contained.

On Aminet here:http://aminet.net/package/comm/net/Roadie

Some screenshots:


The Main Window


Showing results of the ShowNetStatus command


Editing an Interface file
Good job!
duga is offline  
Old 11 June 2019, 18:02   #18
gdonner
Ancient Amiga User

gdonner's Avatar
 
Join Date: Mar 2018
Location: Elkhart / United States
Posts: 47
Yes, very nicely done! And v1.1 is now available, too:

https://aminet.net/comm/net/Roadie.lha
gdonner is offline  
Old 11 June 2019, 21:34   #19
utri007
mä vaan
 
Join Date: Nov 2001
Location: Finland
Posts: 879
Quote:
Originally Posted by Olaf Barthel View Post
I totally agree to that. For example, the GUI can validate the IP address entered and refuse to accept invalid/unsuitable input (explaining why it is invalid/unsuitable). By the time Roadshow gets to look at the configuration file it cannot do much more than reject such input, which is made worse by the fact that during system startup it's difficult to even show an error message

Early input validation is crucial. While the Roadshow documentation states that familiarity with setting up the network configuration is required, I doubt that those users who run into difficulties will find this notion helpful, to say the least (who reads documentation anyway?).

Again, this is a problem born out of how/when the interface address acquisition occurs It could be mitigated by moving this particular task to a later stage when the Workbench is already open and error messages are easier to display and to record.

Almost 19 years in, I haven't come up with a decent solution to this problem, which is in part caused by design decisions which sidelined error handling and reporting. AmigaOS lacks an error logging and reporting mechanism, which affects the entire early system startup process (with the boot shell executing the S:Startup-Sequence script). If anything goes wrong during S:Startup-Sequence execution it's very hard to figure out what happened, and it's worse for S:User-Startup execution which is likely to be immediately followed by LoadWB and EndShell: the boot shell window closes instantly after it has briefly shown any error messages.

If you want to have another look at the DHCP client doing its job and not getting anywhere fast, or failing, I would recommend editing the interface configuration file, changing the line #debug=yes to debug=yes, entering NetShutdown followed by AddNetInterface <name of your network interface>. That should cause Roadshow to start over, open a debug output window and display every step of the DHCP process. If the DHCP process fails for you, the debug output might help in tracking down the cause of the problem.

The DHCP negotiation takes a bit longer (60 seconds) because the client verifies that the IPv4 addresses it was offered are not currently in use. Thus, a timeout has to occur before Roadshow accepts it. You can change that timeout with the TIMEOUT parameter or icon tool type. The minimum are 10 seconds. Yikes, I seem to have (as usual) overengineered this one, neglecting the usability of the interface setup



Neither the AmigaOS4 nor the 68k version of Roadshow show the DHCP debug output by default, and the interface timeout (unless overridden) is set to 60 seconds, too...
Tested Roadshow with Roadie GUI, it does what it promises.

Another option for a GUI, would be ask help from Chris Young. He is a author of Netsurf and most likely only person who has experience to backporting AOS4 Reaction GUI to OS3.5/9. That would be limited to OS3.5/9


How about starting Roadshow from WBstartup? Would it make status/error reporting easier?
utri007 is offline  
Old 17 June 2019, 13:52   #20
Olaf Barthel
Registered User
 
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 200
Quote:
Originally Posted by utri007 View Post
Tested Roadshow with Roadie GUI, it does what it promises.

Another option for a GUI, would be ask help from Chris Young. He is a author of Netsurf and most likely only person who has experience to backporting AOS4 Reaction GUI to OS3.5/9. That would be limited to OS3.5/9
I've been so thoroughly burned by trying several times over to get a comprehensive GUI for all that Roadshow does off the ground, and failing, it's hard for me to even think about trying again now

Quote:
How about starting Roadshow from WBstartup? Would it make status/error reporting easier?
It would make practically all the problematic aspects easier to deal with which the current approach suffers from. The downside is in that you could not leverage the early availability of the network in the S:User-Startup file, which can be really useful. For example, starting the network, followed by starting the smbfs file system is a common pattern.

Let's say I find a way to move the network startup procedure from S:User-Startup into the SYS:WBStartup drawer. Then I'd have to deal with services (such as smbfs or FACTS) which expect the network to be operational when they start up.

One way to approach this would be to introduce script execution to Roadshow, which means that interface state transitions (between online to offline) would cause script files to be executed. Script files would also be executed when Roadshow as a whole transitions between fully operational network and network operations unavailable states. This should be relatively easy to implement, with the complex part being detecting the state changes and figuring out how to deal with state changes which occur while the scripts are still being executed which were triggered by the previous state change. But it leaves out how to deal which are not commonly started from script files, e.g. FACTS. I would not like to reinvent the SYS:WBStartup drawer for Roadshow.

Error reporting in general would have to be improved, too. All the shell commands which are part of Roadshow are designed to print output to the console. A single startup procedure triggered by a program launched from the SYS:WBStartup drawer would have to reproduce the functionality of both AddNetInterface and give useful hints about the errors it encounters trying to bring up the network. That would take quite some work to make it do the job well. One major drawback of launching the network from S:User-Startup is that error messages can neither be displayed, nor saved for later inspection, you just observe that things didn't work if they didn't work

What do you think? Is this is in any way a useful path to follow? I would start by looking into how to make the state changes triggering script file execution work, since this is something which other programs could build upon. Opening up the closed parts of the design should be beneficial.
Olaf Barthel is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Roadshow 1.13 released AndreasM News 26 08 May 2018 17:58
Roadshow incompatibility, AmiTCP, Poseidon and AmigaExplorer... does it work for you McTrinsic support.Apps 15 18 February 2018 20:14
Roadshow 1.12 released AndreasM News 101 27 January 2017 16:16
Cannot mount NFS shares with genesis/amitcp on amithlon slartibartfass support.Apps 9 13 March 2016 17:24
Trying to run RoadShow Retrofan support.Apps 10 10 May 2013 21:00

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09317 seconds with 13 queries