@olsen

Quote:

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.

This is what I was referring to when I brought up porting Linux apps. Or any app expecting threads. Pthreads or whatever is used on OS4 simulates threads by creating a child process. The problem, of course, is that a child process is still another process out of the parent process context. Now, some code likes to open the network stack in one thread and access it on another. This will break here obviously. Now, if code is opening libraries in one process, accessing them in another and, in the worse case, closing them in yet anoher process; that code is dirty. It is in an AmigaOS context anyway. I don't know what an easy solution to this would be. I don't know if Roadshow has a static lib wrapper suitable for porting. But perhaps YAP (yet another process) could be spawned from this virtual bsdsocket lib, that does all the management and access from one process, a central API that passes control to the socket process. Yap yap yap.

Quote:

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...

Okay. Would explain why every time I read about SANA it's listed as SANA-II.

Quote:

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.

From a glance the link layer is the lowest software layer. Either way it looks possible to detect changes. Though not always easy to implement changes in code to do so.

Quote:

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.

Well that was sounding positive until it started to get murky.

Quote:

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.

So close and yet no cigar.

Quote:

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).

Ah yes, I tend to forget that. It's just that the terminal commands always look dated. When are they going to catch up with AmigaDOS command templates? Linux system code tends to be C which really looks dated these days now C++ is all over the place. And the use of all lower case in function names in ScoreSpace llkely doesn't help the look.

Quote:

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.

Well that's good and bad. Good it can be updated but bad that no group is working on it. How would a physical layer like WiFi fit into Roadshow? WPA Enterprise? It needs user and pass like other networks but also scanning for SSIDs is a specific part of it for an easy UI.

Last edited by Hypex on 21-May-2020 at 05:40 PM.
Last edited by Hypex on 20-May-2020 at 04:25 PM.

@Petah

Quote:

Petah wrote: @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?

The BSD socket interface is the industry standard, for better and worse. Portability is important, but more important is whether or not you can solve the problem robustly for which a network API is available.

Before the BSD socket interface became entrenched, there were several attempts to offer APIs with comparable functionality, such as the TLI (transport layer interface) which shipped with AT&T Unix, and its later incarnation within the X/Open transport interface (XTI). And that's not counting stuff such as NetBIOS and Novell Netware which were limited to local networks. I'm probably forgetting whatever IBM was selling, but then I never was exposed to that beyond what I learned at university about token ring networks (and IBM's considerable efforts to kill datagram-based networking in the cradle).

So there is plenty of reason to look beyond what the BSD socket interface could do. Holger Kruse hinted that he was working on a more Amiga-mannered network API while Miami was still under development, but I recall that it was never widely published, if it was indeed finished and ready for testing.

Question is, what would you want an Amiga-specific exec-device based solution to accomplish, and what problems should it solve better than what the AmiTCP architecture and its API can provide for?

You could go straight to the network driver itself and receive/send packets/datagrams through it. That will work well for the local network, but saying that it's a bit hard to use is probably underselling the challenge. In 2016 I wrote a TFTP client for the Amiga which uses only the SANA-II driver functionality (see https://github.com/obarthel/amiga-sana-ii-tftpclient), which also serves as a complete example of how to do SANA-II setup, I/O and teardown like a TCP/IP stack or Envoy would do it. With a bit of nice packaging this could be useful.

The AmiTCP API, which reproduces the 1988/1989 BSD socket interface (and then some), supports both synchronous and asynchronous operations, blocking and non-blocking I/O, with designated API functions for polling and for waiting for input/output/exceptional events to happen. This integrates rather well with the Amiga operating system, and you don't have to "spawn" a separate Process to handle blocking I/O. Granted, the underlying mechanisms, such as asynchronous I/O, are grafted onto existing exec signalling and feel a bit off, but the job they do is adequate. It just doesn't mesh so well with standard exec device I/O. There is no place for the use of of the Amiga-typical message passing.

Last edited by olsen on 21-May-2020 at 10:39 AM.