I find RoadShow on OS4 to very way too stiff and unable to handle any change in network connectability.

Restarting it requires removing the bsdsocket.library from memory, which is often impossible since it is being held open by (potentially buggy or crashed) programs.

Had I written this I would have made bsdsocket.library a facade that always exists, and all connectivity happens behind it. That way any changes could be made more or less transparantly to programs using it. Sure, swiching adapter would potentially disconnect all sockets, but that's something most programs can handle. Having the entire library removed is not.

If it worked this way we could have VPN virtual networks that could be logged into in runtime, like on any other platform. It would be possible to move the network cable from one router to another and having it automatically reconnect behind the scenes. That latter should work in the current configuration also, but it doesn't.

I think windows may actually have solved these problems the best of all systems. Changing adapters (VPN), whiching on or off WiFi, plugging in/out cables, moving cables. It's all seemless and all connected programs stay up (invisible auto-reconnect on connection reset by peer etc), audio/video streams are unaffected.

Miami was better at this than RoadShow because it allowed disconnect/redial/reconnect without removing bsdsocket.library, so it is possible.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Just using the command line to disable or enable the network connection does not do it? I assumed that it would.

Or is it too much of a pain to do that? Maybe a very simple GUI front end would be helpful.

@10MARC

Just noticed I posted in the wrong forum, but anyway...

You mean NetShutdown? This is the very command that tries to remove bsdsocket.library from memory. Something that hardly ever works on my system.

It tries to send Ctrl+C to all programs using it. Something that isn't standard on AmigaOS, especially not for GUI apps. AmIRC for example, just crashes on Ctrl+C, leaving bsdsocket open of course, making NetShutdown hang. Making it impossible to bring up the network again. Reboot is the only option.

Other programs, like AmigaAmp (which can stream radio) ignores Ctrl+C.
MPlayer (which can also stream) is buggy and opens more instances than it closes, which means bsdsocket can never be removed.

Removing the library just isn't the right way to do this. It should just disconnect the sockets and close itself on the backend, but remain in memory. It should behave as if you unplugged the cable, or disconnect and replying connection refused or something to apps trying to reconnect.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

C:RemoveNetInterface

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Deniil715

Quote:

I find RoadShow on OS4 to very way too stiff and unable to handle any change in network connectability.

This tends to be blamed on the underlying SANA drivers which I read somewhere don't support cable drop outs. Sounds silly. There were more physical cables in use back then and no one thought to include a way to detect if a cable fell out and to reconnect?

Quote:

Miami was better at this than RoadShow because it allowed disconnect/redial/reconnect without removing bsdsocket.library, so it is possible.

ISTR that iBrowse could be left open while Miami wasn't connected. But it may have opened the library for each request. Which seems inefficient.

Roadshow is meant to be in the system but where is the GUI? A bunch of WB apps don't exactly help when you need to check or reconnect the network. Sometihng in the title bar or dock would help. The OS4 setup is a bit crass when compared to Linux. Especially the shell output from a GUI.

Another gripe leveled at Roadshow is the library setup. The library can only be used with the process that opened it. As each base is unique. Now this would be fine, as it is a library standard, and is known about. But when porting Linux software it becomes a problem because Linux apps expect to access sockets across threads. But AmigaOS only has "fake" theads, that technically are another process, so the system breaks.

@10MARC

Quote:

Just using the command line to disable or enable the network connection does not do it? I assumed that it would.

Command line? Yes OS4 brings Amiga standard back to the 80s's. I've done it that way and it is buggy. It tends to hang. And I tend to reboot.

Quote:

Or is it too much of a pain to do that? Maybe a very simple GUI front end would be helpful.

Yes it is a pain when forced manual typing doesn't work either. A GUI frontend should be part of it. But if it hung as well it won't be helpful.

It's a bit like mounted devices on Amiga that can't actually be dismounted due to the design. And drives that don't detect disk changes so a DiskChange command must be issued from CLI to do it. Instead of the system detecting it or refreshing it when you access it.

Linux apps? It’s not call bsdsocket.library for nothing, you know - maybe look elsewhere for sources... :)

And yeah, OS4 variant of Roadshow is buggy and lagging behind the OS3 variant, which benefits from not being entangled in Hyperion OS development schemes.

Last edited by kolla on 17-May-2020 at 07:37 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Deniil715

Quote:

Deniil715 wrote: I find RoadShow on OS4 to very way too stiff and unable to handle any change in network connectability. Restarting it requires removing the bsdsocket.library from memory, which is often impossible since it is being held open by (potentially buggy or crashed) programs.

No good way around that, I'm afraid. This is baked into what passes for the architecture of the BSD Unix TCP/IP stack as attached to the AmiTCP API and its kernel interface design.

The function calls which the software makes into the kernel code can get stuck anywhere between the interface (which makes sure that no two callers can access the non-reentrant parts of the TCP/IP stack at the same time) and the kernel code itself.

This is not a modern design by any means. If you'd build something like that today, you'd try to use an embeddable TCP/IP stack which can run in user space, rather than in Unix kernel space.

Quote:

Had I written this I would have made bsdsocket.library a facade that always exists, and all connectivity happens behind it. That way any changes could be made more or less transparantly to programs using it. Sure, swiching adapter would potentially disconnect all sockets, but that's something most programs can handle. Having the entire library removed is not.

This was not an option, some 20 years ago

The shortcomings and limitations you point out are what drops out of the tree if a mild breeze so happens to gently shake its leaves a little bit. In the operating system from which the TCP/IP stack comes from you can at least kick the unruly crashed program out, but this is not so with the Amiga. On the Amiga side you don't have the building blocks which allow for that. For example, arbitration to kernel level data structures works very differently. The closest thing we have to that is the Forbid()/Permit() pair, and they only have one level of escalation which overrides lower levels of locking protocols.

Quote:

If it worked this way we could have VPN virtual networks that could be logged into in runtime, like on any other platform. It would be possible to move the network cable from one router to another and having it automatically reconnect behind the scenes. That latter should work in the current configuration also, but it doesn't. I think windows may actually have solved these problems the best of all systems. Changing adapters (VPN), whiching on or off WiFi, plugging in/out cables, moving cables. It's all seemless and all connected programs stay up (invisible auto-reconnect on connection reset by peer etc), audio/video streams are unaffected. Miami was better at this than RoadShow because it allowed disconnect/redial/reconnect without removing bsdsocket.library, so it is possible.

Miami was also free to create a new instance of bsdsocket.library in memory when it needed to. Roadshow's bsdsocket.library is a "real" disk-loaded shared library. Once it's in memory, you can't knock it off again.

@Deniil715

Quote:

Deniil715 wrote: @10MARC Just noticed I posted in the wrong forum, but anyway... You mean NetShutdown? This is the very command that tries to remove bsdsocket.library from memory. Something that hardly ever works on my system.

Well... actually it first hollers "everybody out of the pool" first (metaphorically), so that each bsdsocket.library user can release it. Only when everybody has stopped using it can bsdsocket.library be safely removed.

Problem is that the bsdsocket.library users are not required to listen to the request. Some don't even handle the request well.

This is how it goes, and it's not for lack of trying

@Hypex

Quote:

Hypex wrote: @Deniil715 Quote: I find RoadShow on OS4 to very way too stiff and unable to handle any change in network connectability. This tends to be blamed on the underlying SANA drivers which I read somewhere don't support cable drop outs. Sounds silly. There were more physical cables in use back then and no one thought to include a way to detect if a cable fell out and to reconnect?

The SANA networking standard was designed specifically for the consumer grade Ethernet technology of the day (1989/1990), which involved the use of a coaxial cable with transceiver hardware attached to it at certain points along its length (10BASE5 and 10BASE2).

From the point of view of the computer on the other side of the transceiver (where the signal coming from the cable came out as a series of zeroes and ones) the transceiver being detached from the cable or there being no traffic on the cable (with the transceiver attached) was indistinguishable.

This is why there is no mechanism in place for the drivers to indicate to the TCP/IP stack (or whoever is listening to the transmission medium) that there's something wrong if the connection dropped off.

There are notification mechanisms for the online/offline commands a network driver is supposed to listen to, but they serve a different purpose. If you tell a network driver to go offline (it can't go offline all by itself), it means that it will release control over the networking hardware. It "unplugs" itself. When it goes "online" again, it will take control over the hardware again.

This is not the same as noticing and reporting that the baseband signal on the medium has gone away along with the carrier which allows auto-configuration over twisted-pair wires. This (10BASE-T and beyond) only became a mainstream technology after Commodore had gone out of business.

That said, working out a mechanism to address this is doable. It's just the majority of the drivers and hardware out there don't necessarily need to support it.

Last edited by olsen on 17-May-2020 at 04:11 PM.

@olsen

Quote:

The closest thing we have to that is the Forbid()/Permit() pair, and they only have one level of escalation which overrides lower levels of locking protocols.

I suggest ignoring kernel space, keep your data in your library, and use Obtain Mutex and Release Mutex.

Quote:

Well... actually it first hollers "everybody out of the pool" first (metaphorically), so that each bsdsocket.library user can release it. Only when everybody has stopped using it can bsdsocket.library be safely removed.

Way can’t bsdsocket.library just be a simple front end for backed network stack.
(API wrapper.)

Last edited by NutsAboutAmiga on 17-May-2020 at 04:29 PM.
Last edited by NutsAboutAmiga on 17-May-2020 at 04:26 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@10MARC

It's called Roadie: http://aminet.net/package/comm/net/Roadie

@kolla

Quote:

Linux apps? It?s not call bsdsocket.library for nothing, you know - maybe look elsewhere for sources... :)

Well, when you have one program you want to port, and the Linux sources did produce an actual binary you don't exactly have reason to go elsewhere. But if you go elsewhere you would need to find a source that doesn't expect modern features like threads or one were threads can be disabled as a configure option. Because, AmigaOS is not thread safe, because technically, it doesn't have threads.

Quote:

And yeah, OS4 variant of Roadshow is buggy and lagging behind the OS3 variant, which benefits from not being entangled in Hyperion OS development schemes.

AEON have been picking up the slack. But, Hyperion has been busy with Cloanto, whose purpose it would seem would be to hurt Hyperion and stall AmigaOS4 development intenionally. Because that is what they have done and I bet they knew that would happen regardless of the outcome. But, even if Hyperion wasn't being sucked dry, doesn't mean develpment would be faster.

@Hypex

"AmigaOS is not thread safe"

No OS is thread safe, ownership of data is something that comes with RUST language, (but its not actually in the language, extension of it.)

And it more catching the problem before you compile your program, then prohibit memory corruption when it happens, so its not can’t happen, RUST just make less likely to happen.

Passing ownership also something that apply to passing data between function, not just treads in RUST.

Last edited by NutsAboutAmiga on 19-May-2020 at 04:37 PM.
Last edited by NutsAboutAmiga on 19-May-2020 at 04:36 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@olsen

Thanks for the information.

Quote:

The SANA networking standard was designed specifically for the consumer grade Ethernet technology of the day (1989/1990), which involved the use of a coaxial cable with transceiver hardware attached to it at certain points along its length (10BASE5 and 10BASE2).

What advances did SANA-II provide?

Quote:

From the point of view of the computer on the other side of the transceiver (where the signal coming from the cable came out as a series of zeroes and ones) the transceiver being detached from the cable or there being no traffic on the cable (with the transceiver attached) was indistinguishable.

At this point, it would be more likely the network would go down, than a cable fall out. For example, dial up internet was common last century, but a solid modem cabling set up wouldn't exactly fall apart. Likewise, Ethernet wouldn't exactly come out, unless you had a broken clip on the plastic plug. Which I did on a few cables later after use and they did come out.

So, signaling aside, was there any function in place to detect a network down? A ping would be the first to come to my mind. Or some kind of heartbeat protocol.

Quote:

This is why there is no mechanism in place for the drivers to indicate to the TCP/IP stack (or whoever is listening to the transmission medium) that there's something wrong if the connection dropped off.

Woud the drivers even know?

Quote:

There are notification mechanisms for the online/offline commands a network driver is supposed to listen to, but they serve a different purpose. If you tell a network driver to go offline (it can't go offline all by itself), it means that it will release control over the networking hardware. It "unplugs" itself. When it goes "online" again, it will take control over the hardware again.

That sounds slightly hard. Whart about a softer approach? Say, rather than the driver go offline, renegotiate the link with the server? Of course in this case there would be no cable drop out but just a network drop out.

Quote:

This is not the same as noticing and reporting that the baseband signal on the medium has gone away along with the carrier which allows auto-configuration over twisted-pair wires. This (10BASE-T and beyond) only became a mainstream technology after Commodore had gone out of business.

Is this why, for example, on Linux it easily detects and reconnects a network interruption? The drivers have evolved with the technology?

Quote:

That said, working out a mechanism to address this is doable. It's just the majority of the drivers and hardware out there don't necessarily need to support it.

Would this be part of a SANA-III standard? Or beyond? Also what happened to SANA-III? AmigaOS4 has been around for over 15 years now.

Last edited by Hypex on 19-May-2020 at 04:48 PM.

@olsen

Thanks for the insight.
So RoadShow isn't in charge of the bsdsocket.library!! Well that explains things. Miami does have a clear advantage then and that's why it behaves a lot better around "live" disconnect/reconnect etc. But it also proves that it's perfectly possible on Amiga

Miami doesn't support DHCP lease time though I wrote a script that would take Miami off- and online in a blipp every 59 minutes back in the A1200 days. That way downloads and streaming (AmiNetRadio) would continue seamlessly forever without the hourly dropout of the IP address lease. Can't do that with RoadShow Luckily it does support DHCP lease though!

I was one of the first fiber users. Got 10/10Mbit ethernet directly into the apartment around 2000-2001 curtacy of BredbandsBolaget who pioneered sweden with fibers across the countrly! In 2004 when competition came crawling up behind they raised everyone to 100/100MBit *for free* (still €30 a month), and it really was 100/100 (not that my Amiga could handle that though). That was the times.... BredbandsBolaget ruled, I remember once they sent an advertising letter with an actual screwdriver attach, saying "You dont' need this when getting broadband from us!" haha I still have it :)

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @olsen Quote: The closest thing we have to that is the Forbid()/Permit() pair, and they only have one level of escalation which overrides lower levels of locking protocols. I suggest ignoring kernel space, keep your data in your library, and use Obtain Mutex and Release Mutex.

I mentioned kernel and user space because these are the terms on which you have to deal with the parts which make up the AmiTCP API and the TCP/IP stack itself which the APIs make use of.

On the Amiga you do not have a separation of kernel and user code, with multiple levels of arbitration mechanisms. If you will, adapted for the AmiTCP API it all becomes "userland" code, with a single SignalSemaphore for arbitration when it comes to access global shared data structures.

Quote:

Quote: Well... actually it first hollers "everybody out of the pool" first (metaphorically), so that each bsdsocket.library user can release it. Only when everybody has stopped using it can bsdsocket.library be safely removed. Way can’t bsdsocket.library just be a simple front end for backed network stack. (API wrapper.)

In part because you cannot make the rules go away which the AmiTCP API design and the AmiTCP architecture imposes.

Each time a client opens bsdsocket.library, it will receive a pointer to a library which was created specifically for it. That library contains Unix kernel userland data structures which map file descriptor numbers to their kernel data structures. Each client has its own set of file descriptors, and this is an API feature.

Because the client eventually calls kernel code, accessing the shared global kernel data structures as needed, each client shares both the CPU and the network resources as it should do in a multitasking environment. This scales rather well.

If you wanted to replace this rather frictionless API/architecture design, you'd have to move the responsibilities which currently the API shoulders into a wrapper and an interface between the wrapper and what is currently the AmiTCP architecture.

While this is doable, I wonder if it can be done both well and scale well, though. You'd still have to deal with file descriptor numbers and what they mean, with managing network traffic, preserving the behaviour of the entire AmiTCP API and make all of this scale well.

The AmiTCP API covers the entire BSD networking interface API, and even parts of the kernel operations, as was in 1988/1989, so it becomes a much bigger challenge to just wrap/proxy it. More complexity, more corner cases, means that invariably you'll be building something that might solve one problem (client crashes, bsdsocket.library can still be expunged) at the expense of introducing another layer on top of an already complex system.

@Hypex

Quote:

Hypex wrote: @olsen Thanks for the information. Quote: The SANA networking standard was designed specifically for the consumer grade Ethernet technology of the day (1989/1990), which involved the use of a coaxial cable with transceiver hardware attached to it at certain points along its length (10BASE5 and 10BASE2). What advances did SANA-II provide?

From what I remember, SANA was the draft standard which was published at the time so that industry and consumer feedback could be gathered and produce the actual standard for production use (that would be SANA-II). I haven't looked at the differences, though. It's been a long time since SANA was published...

Quote:

Quote: From the point of view of the computer on the other side of the transceiver (where the signal coming from the cable came out as a series of zeroes and ones) the transceiver being detached from the cable or there being no traffic on the cable (with the transceiver attached) was indistinguishable. At this point, it would be more likely the network would go down, than a cable fall out. For example, dial up internet was common last century, but a solid modem cabling set up wouldn't exactly fall apart. Likewise, Ethernet wouldn't exactly come out, unless you had a broken clip on the plastic plug. Which I did on a few cables later after use and they did come out. So, signaling aside, was there any function in place to detect a network down? A ping would be the first to come to my mind. Or some kind of heartbeat protocol.

SANA-II covers strictly the link layer only, and what it could do in 1989/1990. As you mentioned, you would have had to involve the layers which build on the link layer to get an idea of whether or not there was a problem with the data transmission. But that's a problem of the time. A few years later when 10BASE-T came around you could detect simple disconnect/connect changes at the layer which SANA-II is responsible for.

Quote:

Quote: This is why there is no mechanism in place for the drivers to indicate to the TCP/IP stack (or whoever is listening to the transmission medium) that there's something wrong if the connection dropped off. Woud the drivers even know?

They would and, as far as I know, some actually do and indicate the state of the link through the existing SANA-II mechanism for online/offline command effects. This tends to be good enough to be useful in this context but renders the purpose of the online/offline commands, as specified, murky. Roadshow will react to the online/offline notification, but it's still not the correct mechanism for the purpose of indicating that the link is no longer operational/is operational again.

Quote:

Quote: There are notification mechanisms for the online/offline commands a network driver is supposed to listen to, but they serve a different purpose. If you tell a network driver to go offline (it can't go offline all by itself), it means that it will release control over the networking hardware. It "unplugs" itself. When it goes "online" again, it will take control over the hardware again. That sounds slightly hard. Whart about a softer approach? Say, rather than the driver go offline, renegotiate the link with the server? Of course in this case there would be no cable drop out but just a network drop out.

This is how it's done, just not on the Amiga... The UTP Ethernet cabling, the network hardware including the switches have enabled this functionality when this technology became mainstream in the 1990'ies. It's just that SANA-II never caught up with that, in spite of all efforts to upgrade it.

Quote:

Quote: This is not the same as noticing and reporting that the baseband signal on the medium has gone away along with the carrier which allows auto-configuration over twisted-pair wires. This (10BASE-T and beyond) only became a mainstream technology after Commodore had gone out of business. Is this why, for example, on Linux it easily detects and reconnects a network interruption? The drivers have evolved with the technology?

Evolved is perhaps the wrong word They were likely written to support it from the very beginning (Linux being a "child" of the 1990'ies).

Quote:

Quote: That said, working out a mechanism to address this is doable. It's just the majority of the drivers and hardware out there don't necessarily need to support it. Would this be part of a SANA-III standard? Or beyond? Also what happened to SANA-III? AmigaOS4 has been around for over 15 years now.

Any standard needs people championing and supporting it. To the best of my knowledge, no group formed to carry the standard forward during the past 2+ decades. One nice aspect of SANA-II is that it is extendable without breaking backwards compatibility. SANA-II was revised several times already, with revision 2 (SANA-IIR2) being the first one. In a way you do not need SANA-III unless you want to go beyond adding new functionality to what exists already.

@Deniil715

Quote:

Deniil715 wrote: @olsen Thanks for the insight. So RoadShow isn't in charge of the bsdsocket.library!! Well that explains things. Miami does have a clear advantage then and that's why it behaves a lot better around "live" disconnect/reconnect etc. But it also proves that it's perfectly possible on Amiga

One man's ceiling is another man's floor I wrote Roadshow so that bsdsocket.library can be a regular disk-loaded library instead of something for which you have to start a program that's responsible for making bsdsocket.library appear. Both AmiTCP and Miami did the latter, and it annoyed me to no end.

Using a regular disk-loaded library also reduces implementation complexity by a good deal.

Quote:

Miami doesn't support DHCP lease time though I wrote a script that would take Miami off- and online in a blipp every 59 minutes back in the A1200 days. That way downloads and streaming (AmiNetRadio) would continue seamlessly forever without the hourly dropout of the IP address lease. Can't do that with RoadShow Luckily it does support DHCP lease though!

Strange... I thought that the DHCP client support in Miami was up to contemporary standards when it was still being maintained. The built-in DHCP client support in Roadshow took a while to mature, and I still haven't found a good solution for lease renegotiation (renewal works, but starting over from scratch is a different procedure).

@olsen

bsdsocket.library is based, AFAIK, on POSIX compatiblity. While it makes sense from a portability perspective, it doesn't resonate very well with how AmigaOS APIs are designed. Do you think it would make sense to approach the API in a different, more AmigaOS friendly manner, perhaps by implementing it as an Amiga device?

_________________
That'll Put Marzipan In Your Pie Plate, Bingo
💻 Pro-Amiga, 🌍 Pro-Globalism, 🍅 Pro-Vegan, 🛦 Pro-NATO & 🇪🇺 Pro-Joint EU Defense Intervention Initiative