Ethernet chit chat...

[Peter]

When Ethernet-based networking is being introduced on the QL, anything that does only concentrate on standard IET protocols, e-Mail and Web not incorporating things like FSERVE or transparent network output that the QL had 25 years ago would be a step backwards.

As far as I know, even the emulator implementations always had this shortcoming. Although those implementaions were magnitudes easier (!) than QL ethernet hardware plus QL native TCP/IP stack plus QL ethernet driver.

I think it is not very helpful to burden even higher demands on what is already close to "mission impossible" (as for a full production release). Better give people some freedom and be thankful if something happens at all.

Asking for a fantastic optimum and calling everything less "a step backwards" might demotivate those who are about to shoulder massive workload.

[tofro]

Nasta,

obviously, there are quite a lot of ways QL networking transport could be implemented on more modern wire - If i were to start on this, I would most probably go for IP Multicast and put the network station number in the payload - as that is the closest you can get to simulate the "bits on the wire - many-to-many" approach QL networking uses. Anything that tries to encapsulate net_ station numbers in IP or MAC addresses is bound to fail latest with sending to the broadcast address (Assuming you live in an IP address pool you own yourself - If not, it might get even worse).

Or it would need a dedicated control plane mechanism to be able to translate QL network station station numbers into IP or MAC addresses.

IP multicast has most parts of such a control plane already implemented and would also make a "Bridge" to native much easier to implement, as the bridge could see all possible QL net numbers present on the IP side as an inherent functionality.

But that assumes a future QL IP stack would be Multicast-enabled, which most embedded stacks aren't. (Don't know for the WizNet stack, have to check)

Tobias

[tofro]

As far as I know, even the emulator implementations always had this shortcoming.

Right. None of the emulators supports such functionality, to my knowledge at least.

[Provocative statement:] That might be the reason why there is close to no software in use that actually uses those stacks.

And exactly that fact made me think what the "killer app" for QL/Ethernet would be.

My (very) personal opinion - Just thinking about possible applications of QL networking:

• I wouldn't use the IP-enabled QL to send emails, I have got better tools on other platforms for that.
• I would definitely not use it to browse the web - I can't imagine a reasonable browser on a platform like the QL that would be able cope with the veriety of today's websites.
• I might (or might not) use it for "old-style networking" like ftp and telnet - Although there's less and less support for that.

So, other than doing a bit of fooling around, a pure Ethernet/IP implementation wouldn't be of much practival use to me.

If, however, support for the file server and good old QL network transparency would be there, that would really be an application I can imagine to use.

On the other hand, I can't see why a plea for that support should de-motivate builders - In my opinion, rather the opposite is true. Most of the code for that functionality has already been around for more than 25 years - It "just" needs to use a different transport.


Tobias

[XorA]

FTP/Fileserver does seem to be the most common use of retro network ports!

[Peter]

FTP/Fileserver does seem to be the most common use of retro network ports!

I have both HTTP and TFTP facilities for file up- and download over ethernet and SLIP.
But having this (instead of nothing) is considered a "step backward".

[Dave]

One simplifying factor I can think of:

This could be used to quickly used to share QL software and move it across the platform gap or direct from QL<->QL or QL<->emulator. It allows a whole other channel of distribution without having to handle physical media. Sandy would certainly like to use it as a way to distribute firmware updates. [1]

Given server support (which I would happily provide, and others could too) there could be all kinds of chat, filesharing, screensharing, .WIN-swapping, ....

The catch is that when you state "things we can already do on a PC" there's an implicit acknowledgement that "well, a PC can do it better anyway" but my view is "and the QL can't do it at all, which needs to be fixed."

[RWAP]

Plus, I guess if we could ever get a hold of Di-Ren (Robin Barker where are you ??) - we could truly launch something like Fleet Tactical Command - which was always designed to run on several QLs and other computers linked together - unfortunately via the QL Network or Amadeus Interlink.....

[Dave]

I think it's completely feasible to replace the NET routines with code that encapsulates it and redirects it to ethernet, transparently to the program itself.

[Nasta]

And exactly that fact made me think what the "killer app" for QL/Ethernet would be.
My (very) personal opinion - Just thinking about possible applications of QL networking:
...support for the file server and good old QL network transparency would be there, that would really be an application I can imagine to use.

On this I wholeheartedly agree. Which was the reason I envisioned it as the first step all those years ago.
As to implementation, keep in minf that the original NET protocol doesn't count on that many stations, and FSERVE on even less, so some sort of 'translation' mechanism to define what is in the network will be needed. Expanding this across a network ypu don't own or control I think is stretching the original NET idea beyond it's limits, but then the original protocol and idea could certainly be built uppon.

[tofro]

And to calm anyone else down - It's for the most part an application, not a driver in a strict sense.

Tobias