@olsen

What exactly does spotify need from the TCP/IP stack that the AmiTCP API cannot provide, and cannot be worked around as far as it sounds?

I've only done some basic TCP/HTTP networking on Linux and Amiga and AFAIR I didn't even need any #ifdefs. Sure, we don't have IPv6, but is that a requirement?

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

Right, I've been a user of current AmigaOS since March of last year and as far as I understand it from my very little knowledge on the subject - OS4 uses Roadshow - AmiTCP makes me think of OS3 - so why all the AmiTCP talk?

_________________

@Deniil715
Ofcourse we can do a workaround of this. What we should help spotify with is putting together
an example of how to communicate via TCP/IP.

On the hardware side. The parts from ACube is on its way.
I use a silverstone case for my Sam460. What do you guys recommend we are using.
Remeber it must look cool. Prefereble with stickers on making it visible in a potentional
press release.

@djrikki

It's because Roadshow, while newer, is still limited by being directly compatible with the AmiTCP interface. This means that it is only capable of the same sort of network functions that AmiTCP is/was - no more, no less.

Having said that though, surely the API could be extended with new functions while leaving the old ones intact, like the 64-bit DOS functions? I know software using the new functions wouldn't work with AmiTCP any more, but for the likes of this, at least it might work on platforms still under development, i.e. OS4, MOS and AROS.

Last edited by Daedalus on 07-Feb-2012 at 01:05 PM.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@Deniil715

Quote:

Deniil715 wrote: @olsen What exactly does spotify need from the TCP/IP stack that the AmiTCP API cannot provide, and cannot be worked around as far as it sounds?

I haven't got the foggiest right now. So far it appears that the Spotify code feels comfortable to perform DNS lookups through an API which does not exist within the AmiTCP domain. AmiTCP contains the bare necessities to perform DNS lookups through an early version of the libresolv code, which is baked into it. It's a much older DNS lookup API than Spotify apparently expects.

Problem here is that you cannot retrofit this API. You might be able to emulate it. You might be able to use conditional compilation to have the client code call the old clunky API instead of the shinier version we don't have. You might be able to simply drop in a more recent version of the libresolv code than what exists as part of the AmiTCP API. There are a lot of options, some nicer, some not so nice.

Mind you, not knowing how the actual Spotify client code looks like, I can only speculate.

Quote:

I've only done some basic TCP/HTTP networking on Linux and Amiga and AFAIR I didn't even need any #ifdefs. Sure, we don't have IPv6, but is that a requirement?

A lot has changed within the socket API in the past decades, and the same is true for the libresolv code. New functions and data structures were tacked on which make accessing the fundamental API services less clunky and more convenient. These niceties passed us by, because the AmiTCP API has remained virtually unchanged since its inception.

@djrikki

Quote:

djrikki wrote: Right, I've been a user of current AmigaOS since March of last year and as far as I understand it from my very little knowledge on the subject - OS4 uses Roadshow - AmiTCP makes me think of OS3 - so why all the AmiTCP talk?

I was referring to AmiTCP in the context of the API it implemented. With one notable exception (INet-225) all Amiga TCP/IP stacks deployed since then (1994) implemented the same API. This is true for Roadshow, too, although I tried to find a backwards compatible approach to extending its API functionality.

@Daedalus

Quote:

Daedalus wrote: @djrikki It's because Roadshow, while newer, is still limited by being directly compatible with the AmiTCP interface. This means that it is only capable of the same sort of network functions that AmiTCP is/was - no more, no less.

You got it

Quote:

Having said that though, surely the API could be extended with new functions while leaving the old ones intact, like the 64-bit DOS functions? I know software using the new functions wouldn't work with AmiTCP any more, but for the likes of this, at least it might work on platforms still under development, i.e. OS4, MOS and AROS.

It's possible; if memory serves, "Miami" added its own APIs without extendig the fundamental AmiTCP API functions, for example. As for Roadshow, I was perhaps unwise to piggy-back its own extended API on the AmiTCP foundations. Rolling these changes back is no longer an option.

Coordinating development on making all AmiTCP-like TCP/IP stacks share common API functionality is, I fear, doomed to fail. Let's try our hands at perfecting the art of herding cats first, shall we?

The 460 just arrived. Now I need to assemble it in some fancy case. Any suggestions?

@Skuggan

The sweedish company :

http://fractal-design.com/

If you send me a signed picture with the spotify people and the 460 , i wil sposor the case

Last edited by eder on 14-Feb-2012 at 12:23 PM.
Last edited by eder on 14-Feb-2012 at 12:22 PM.

@eder

Its a pity it wont fit in the mini case they have. I want it to be small so its easier to transport and not taking up big space at the spotify office.

You wish is noted. Maybe we can hand out signed photos to all contributors. :)

@Skuggan

Ok

would be nice, if so i am allready in..

Lykke til

Last edited by eder on 14-Feb-2012 at 12:58 PM.

@olsen

Quote:

The issue here is the "what it cannot do" aspect. Unlike the Winsock API I mentioned above, nobody is in charge of laying down what the AmiTCP API should or should not provide. Due to compatibility concerns (practically all Amiga IPv4 networking software uses the AmiTCP API), it cannot be changed. The kind of functionality available in AmiTCP in the early 1990'ies is exactly what is available today in Amiga TCP/IP stacks such as MOSnet, NetStack and Roadshow, to name just three.

Hi Olaf

Clearly the API is outdated and needs to be replaced. We also need IPv6. so, the question is, is anybody working on writing a new TCP/IP stack (or massively overhauling Roadshow)? We could have a new bsdsocketv6.library with the new incompatible API, and replace bsdsocket.library with stubs to call the new functions for old applications (that's they can't all be added to bsdsocket.library or if that is too complicated to do). With the IPv4 address pool running out this needs to be started on ASAP, if it hasn't already.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Chris_Y

I think that Hyperion need to go back to basics for OS4.2 - Full TCP/IP support / Networking and Printing support.

That is what I feel OS4.2 should be all about.

_________________
No cause is lost if there is but one fool left to fight for it.

@Mikey_C

You forgot mic support for tunenet

@Skuggan

Quote:

Skuggan wrote: The 460 just arrived. Now I need to assemble it in some fancy case. Any suggestions?

That was quick!

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

@Chris_Y

Quote:

Chris_Y wrote: @olsen Quote: The issue here is the "what it cannot do" aspect. Unlike the Winsock API I mentioned above, nobody is in charge of laying down what the AmiTCP API should or should not provide. Due to compatibility concerns (practically all Amiga IPv4 networking software uses the AmiTCP API), it cannot be changed. The kind of functionality available in AmiTCP in the early 1990'ies is exactly what is available today in Amiga TCP/IP stacks such as MOSnet, NetStack and Roadshow, to name just three. Hi Olaf Clearly the API is outdated and needs to be replaced.

Allow me to disagree on both counts

The API we have today is used by practically all available Amiga networking software. It's reasonably well-documented, as it conforms to the basic BSD socket API functionality, which has not changed radically in the last 20 years.

What has changed in the last 20 years is the DNS lookup API. The version cast into bsdsocket.library is simple and close the original, as first deployed in the late 1980'ies/early 1990'ies. This API still works, it's just not as convenient as one might want it to be. Meaning, you'll get there, but you won't be traveling in style.

None of this has to be replaced because it lacks capabilities which are vital to software operations.

Quote:

We also need IPv6. so, the question is, is anybody working on writing a new TCP/IP stack (or massively overhauling Roadshow)? We could have a new bsdsocketv6.library with the new incompatible API, and replace bsdsocket.library with stubs to call the new functions for old applications (that's they can't all be added to bsdsocket.library or if that is too complicated to do). With the IPv4 address pool running out this needs to be started on ASAP, if it hasn't already.

I doubt whether any of this represents a viable development path.

First thing, IPv6 is still not ready for prime time, unless you are deploying it in the intranet of a large corporation, a university campus, or, say revamping the entire network infrastructure of a chinese province. There are interoperability issues which are still hard to resolve, and only a lot of work and time spent on the effort will make them go away. In other words, don't hold your breath. IPv6 will come around one day, but it won't be tomorrow. And when it comes around, it will not instantly displace devices which are restricted to IPv4, since there are so many of them around, which will take another couple of years to be replaced. Don't jump to the conclusion that because the public IPv4 address space has run out, the sky will fall in what must be minutes, if not seconds. We already have a workaround for scarce IPv4 address spaces: it's called "network address translation", which has been around for decades. And there will be IPv6 to IPv4 NAT mechanisms in place when the time comes.

As for the stubs/monkey wrenching, this won't fly due to how the bsdsocket.library architecture works out. Each time you open the library, it creates state information specific to the opener. This state information ties into the original BSD kernel's process data structure. It's fundamentally unsound to even try patching that. The only alternative I can see is that the IPv6 support, etc. would have to be added to a sister library API of sorts which transparently hooks into what we already have. This is going to be ugly, but there is only so much that can be done, the API definition being as rigid as it is.

Finally, as for porting another TCP/IP stack, it's doable, it's hard work, it takes its time to make it complete. You could start with a BSD stack, like it's customary, or try and make one of the embedded solutions work (lwIP, uIP, etc.). Trouble is, who's going to pay for the work? This isn't a weekend project. I myself had the first emryonic Roadshow running within a month. But it took months and years to integrate, polish, extend and debug the whole thing.

@Mikey_C

Quote:

Mikey_C wrote: @Chris_Y I think that Hyperion need to go back to basics for OS4.2 - Full TCP/IP support / Networking and Printing support. That is what I feel OS4.2 should be all about.

You're talking about basic utility functions which ought to be taken for granted. The TCP/IP stack ought to work, the printer should be printing, like there should be water available from the tap, and there should be a bright lightbulb when you flip the switch.

i'm not sure how any modest improvements in these areas will count as selling points. Just saying

why do i have an impression that all we so much desire is another linux, which we might end up with, after all os components had been reasonably updated.

Last edited by wawa on 15-Feb-2012 at 10:38 AM.

@wawa
Oh no. Linux is linux. Don't want AmigaOS to be another Linux.

@wawa

Quote:

wawa wrote: why do i have an impression that all we so much desire is another linux, which we might end up with, after all os components had been reasonably updated.

You're not far off the mark. What we want is a platform which can run a selection of current software with performance and features comparable to other computer platforms, if not better.

It's the technology which should enable this that's making it difficult for us. AmigaOS and its components evolved along a path very different from the one which Linux/POSIX and Windows, respectively, ended up following.

Without going as far as passing judgement on what is better, there at least ought to be some common ground here, but the emphasis is strictly on "some".

We have our limitations on AmigaOS, and we have to live with them somehow.

Last edited by olsen on 15-Feb-2012 at 10:56 AM.