Navigation
« 

Anonymous




Register
Login
« 
« 

Amiga Future

« 

Community

« 

Knowledge

« 

Last Magazine

The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
The Amiga Future 167 was released on the March 5th.

The Amiga Future 167 was released on the March 5th.
More informations

« 

Service

« 

Search




Advanced search

Unanswered topics
Active topics
« 

Social Media

Twitter Amigafuture Facebook Amigafuture RSS-Feed [german] Amigafuture RSS-Feed [english] Instagram YouTube Patreon
« 

Advertisement

Amazon

Patreon

« 

Partnerlinks

Roadshow and WHDLoad

Support Roadshow

Moderators: AndreasM, olsen

daxb
AFF Profi
AFF Profi
Posts: 614
Joined: 10.11.2002 - 01:42

Re: Roadshow and WHDLoad

Post by daxb »

olsen wrote: 25.07.2022 - 11:40Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".
Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.
olsen
CygnusEd Developer
Posts: 167
Joined: 06.06.2006 - 16:27

Re: Roadshow and WHDLoad

Post by olsen »

daxb wrote: 26.07.2022 - 11:14
olsen wrote: 25.07.2022 - 11:40Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".
Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.
I am afraid there is no halfway house between the TCP/IP stack running and it not running :(

The design of AmiTCP never took into account that you might want to stop the TCP/IP stack without the willing cooperation of the programs which are still holding onto it and are expecting a specific well-defined behaviour.

Roadshow attempts to do as much as can be done without breaking the implied and explicit rules of the TCP/IP stack, how client software uses it, and how the network device drivers make use of it. In the end that may not be enough because of the unpredictability of the many moving parts involved.

For example, some network device drivers cannot be closed safely, even if all the currently queued I/O requests have been cancelled and taken out of service (Amiga device drivers tend to be a very mixed bag, which goes double for network device driver and in particular legacy drivers for legacy hardware which never received updates and bug fixes). Client code may still be executing TCP/IP kernel code, waiting for a condition change which will never arrive, but removing it by force from that queue may render the signal semaphore which polices access to kernel data inconsistent. Roadshow is chock full of such interlocking, concurrent operations and not just the TCP/IP kernel.

The "NetShutdown" command is limited to delivering safe and predictable outcomes. Either it succeeds or it fails at shutting down the network. If it fails, then this needs to be respected and handled accordingly. The only safe way to avoid not being able to shut down the network is not starting it in the first place and nothing I could do to the TCP/IP kernel code could change that.
daxb
AFF Profi
AFF Profi
Posts: 614
Joined: 10.11.2002 - 01:42

Re: Roadshow and WHDLoad

Post by daxb »

Ok, I understand and back in the days when I used 56k modem I had noticed that sometimes MiamiaDX couldn't go off for some unknown reason. Further, I think it (FORCE option) wouldn't help in jjmarcos case. The WHDLoad options should help more.

jjmarcos you could try to find out what is the reason that stops Roadshow shutdown and then just avoid it. However, this might not be possible.
jjmarcos
AFF Anwärter
AFF Anwärter
Posts: 12
Joined: 08.12.2021 - 07:24

Re: Roadshow and WHDLoad

Post by jjmarcos »

Hello everyone!
I'm gonna reply to myself 2 years later :o

The thing is that I've been putting together yet another A1200, in this case with a PiStorm32 and a CM4 (it's freaking fast btw!)
I stumbled upon the same issue again. I thought that maybe it was related to the PCMCIA card I was using, so I got a Netgear that uses a different driver (cnet.device). Same behaviour I'm afraid, if the network is configured, I get a black screen launching WHDLoad games, even after running NetShutdown.

So, what is the solution? Well, besides running NetShutdown, I also run CardReset TICKS 50 from this Aminet package: https://aminet.net/package/util/boot/CardReset

The way that I have it configured, if it helps anyone else, is:
Roadshow starts on boot, S:user-startup calls S:network-startup
I have a drawer on my Workbench Screen with icons to launch AGS and TinyLauncher (WHDLoad games). Besides that, I have three scripts right there:

stop-network: I wanna play something, let's shutdown the network for real.

Code: Select all

echo Stopping network services...
wait 1 sec
C:NetShutdown
wait 1 sec
C:CardReset TICKS 50
quit
start-network: Useful when I have stopped the network to play something, but I want to get back online after playing. The timeout parameter is pretty handy if you configure the IP address via DHCP.

Code: Select all

echo Starting network services...
AddNetInterface DEVS:NetInterfaces/~(#$.info) QUIET TIMEOUT=90
echo Done!
wait 1 sec
quit
show-network-status

Code: Select all

ShowNetStatus
wait 3 sec
quit
I do not run these scripts as pre or post WHDLoad tasks, I prefer to run them manually once I want to start playing or I have finished playing.
Also, I have a hardware PCMCIA bug reset fix (Rastport KA21B) in place, so I do not run on boot CardPatch or any other software solution for the normal operation of the network card.
In the end I ditched the Netgear and sticked to the 3com Etherlink III (3c589), way faster and reliable!

Hope it helps!
Juppstein
Grade reingestolpert
Grade reingestolpert
Posts: 4
Joined: 31.12.2023 - 13:24

Re: Roadshow and WHDLoad

Post by Juppstein »

Here I'm using Roadie to switch off the net before starting a whdload, afterwards it's just clicking Connect to go online again. While it's not an "automatic" solution it's convenient enough for me to not be bothered by it 😁

https://aminet.net/package/comm/net/Roadie
jjmarcos
AFF Anwärter
AFF Anwärter
Posts: 12
Joined: 08.12.2021 - 07:24

Re: Roadshow and WHDLoad

Post by jjmarcos »

Yeah, it seems Roadie also does the job.
I'd love finding out earlier, but since I took the time to create the scripts, I'll keep using them ;)
jeffseid
Grade reingestolpert
Grade reingestolpert
Posts: 1
Joined: 03.01.2024 - 15:28

Re: Roadshow and WHDLoad

Post by jeffseid »

yevnovikova wrote: 03.01.2024 - 15:35 Gute Skripte, und für solche Dinge muss man heutzutage nicht einmal mehr Fullstack-Entwickler einstellen :)
Why do you bump an old thread?
Post Reply