Internet and the QL

A place to discuss general QL issues.
User avatar
Peter
Aurora
Posts: 899
Joined: Sat Jan 22, 2011 8:47 am

Re: Internet and the QL

Postby Peter » Sun May 19, 2019 10:35 pm

Dave wrote:A real TCP/IP card is only useful if we have access to an encryption engine.

I find it exaggerated to say that TCP/IP is useless without encryption. It can still be used for LAN connections, internet connections from QL to QL, and many websites.
From my experience with QLwIP I see the largest problem in the requirement of encryption for email server connections. (Which does not even make too much real sense, as long as the contents is usually cleartext.)

Dave wrote:It would take a QL several days to encrypt or decrypt a single packet.

Encryption/decryption does not solve the next problem:
It would take similarly long to render a webpage (in the hypothetical assumption the QL had a graphical browser).

Dave wrote:The stack needs to be run on a fast external device that can handle encryption in real time.

But what kind of encrypted internet data would you process on a QL? (Except text email which would still make sense on slow machines.)

I see a difficulty in "outsourcing" TCP/IP: It leads to the emulation route, moves development away from the native side. Eventually it is no longer clear why we do not emulate the rest of the QL side also, if the network coprocessor has much more processing power anyway...


User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Internet and the QL

Postby Dave » Mon May 20, 2019 2:54 am

Peter wrote:I find it exaggerated to say that TCP/IP is useless without encryption. It can still be used for LAN connections, internet connections from QL to QL, and many websites.
From my experience with QLwIP I see the largest problem in the requirement of encryption for email server connections. (Which does not even make too much real sense, as long as the contents is usually cleartext.)

I don't think TCP/IP is useless without encryption, but a TCP/IP device made now will already not have access to half the services available, and this will only increase in the future.
Peter wrote:It would take similarly long to render a webpage (in the hypothetical assumption the QL had a graphical browser). But what kind of encrypted internet data would you process on a QL? (Except text email which would still make sense on slow machines.)

I was thinking encrypted email, SSH, SFTP, secure chat, etc.
Peter wrote:I see a difficulty in "outsourcing" TCP/IP: It leads to the emulation route, moves development away from the native side. Eventually it is no longer clear why we do not emulate the rest of the QL side also, if the network coprocessor has much more processing power anyway...

Almost all the existing communications software on the QL is designed to use a Hayes compatible modem. This method we implemented is Hayes AT compatible to the point where devices can function across a TCP bridge, transparently.

I consider that far more immediately useful that some device that doesn't run the stack for the vintage OS with some hardware abstraction layer to present a common and familiar interface. This both protects us by allowing us to use the same mechanism for future versions of the wifi chipset, AND it makes the use of it immediately accessible to everyone who knows how to use a modem -- no extra knowledge required.

That's not a worse or less viable choice than using a chip that currently has no released OS support, isn't used by any released software (vintage or otherwise) and even when it does, will have to use plaintext or some archaic form of encryption that is not compatible with modern and future systems.

Both are choices. Both are valid. Both get people online with their QLs. One is easier and more abstracted, and gives less control but fewer difficulties. The other is more fundamental, and requires deep and intimate knowledge of the OS and additional tools to operate. So one suits me and my skills, and one suits you and your skills.

That's why they do not each appeal to us equally.


User avatar
1024MAK
Super Gold Card
Posts: 541
Joined: Sun Dec 11, 2011 1:16 am
Location: Looking forward to summer in Somerset, UK...

Re: Internet and the QL

Postby 1024MAK » Mon May 20, 2019 7:54 am

As browsing the Internet even using older PCs is now getting more and more painful, and as more and more emails contain photos, images and attachments (and most of the time, the user can’t select which emails get downloaded), I think the most useful reason for having Ethernet on a QL would be the same reason as applicable to other 1980s home computers. That is for file transfer within a users own LAN or between other like minded users across the web. As such, encryption for this would not be needed.

It would also be possible to connect to simple HTML sites (designed to be simple with 1980s home computers in mind) and download files from such sites. Encryption may be desired for this application, not because we need it on the QL, but to keep modern browsers happy.

Obviously connecting to bulletin boards is not going to be too difficult whether via a MODEM like Interface or via new software.

What do other members here think they would do with an Ethernet equipped QL of compatible?

Mark


QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
User avatar
vanpeebles
Commissario Pebbli
Posts: 2136
Joined: Sat Nov 20, 2010 7:13 pm
Location: North East UK

Re: Internet and the QL

Postby vanpeebles » Mon May 20, 2019 9:15 am

1024MAK wrote:What do other members here think they would do with an Ethernet equipped QL of compatible?Mark


Connect to the QL chat, and also QL compatible websites with software etc ready to run. Might be easier to give new users a taste of QL software via the internet, than having to track down floppy drives etc. Getting rare to have a PC with a floppy in the home now.


User avatar
Pr0f
Gold Card
Posts: 377
Joined: Thu Oct 12, 2017 9:54 am

Re: Internet and the QL

Postby Pr0f » Mon May 20, 2019 9:38 am

Basic TCP/IP functionality - TFTP/FTP, telnet, SMTP, DNS, and DHCP - basic IOT type capability really.

I have a DALLAS TINI device that uses a beefed up 8051 core and that manages basic TCP/IP on a 10Mb wired LAN.


User avatar
Peter
Aurora
Posts: 899
Joined: Sat Jan 22, 2011 8:47 am

Re: Internet and the QL

Postby Peter » Mon May 20, 2019 1:09 pm

1024MAK wrote:As browsing the Internet even using older PCs is now getting more and more painful, and as more and more emails contain photos, images and attachments (and most of the time, the user can’t select which emails get downloaded), I think the most useful reason for having Ethernet on a QL would be the same reason as applicable to other 1980s home computers.

The email client I developed for my (yet unreleased) QLwIP native TPC/IP suite supports a useful POP3 feature for this reason. It allows to retrieve email header informations that are available on the server, before anything is downloaded. The emails can then be individually selected for download, based on length, sender, topic, date, etc. It even supports the pointer environment. But sadly, most email providers don't allow unencrypted client connections anymore. (Which does not provide much real security, because the emails go plaintext over the internet afterwards...)

I wonder if a pragmatic approach, like finding or hosting classic email servers, could help without "outsourcing" encryption to a non-native CPU. (By the way, I'm not sure that an encryption engine outside the QL would automatically lead to the development of an email client which can handle it.)

1024MAK wrote:It would also be possible to connect to simple HTML sites (designed to be simple with 1980s home computers in mind) and download files from such sites.

Yes and QLwIP includes a textmode webbrowser which can do that, e.g. tested with Dilwyn's site. Even using popular sites like Google Search still works. A release of the software is not near, but it has been demonstrated in public, and is at least proof what a relatively slow QL compatible machine like the Q68 (or a fast machine like the Q60) can realistically do.


User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Internet and the QL

Postby Dave » Mon May 20, 2019 2:34 pm

Peter wrote:I wonder if a pragmatic approach, like finding or hosting classic email servers, could help without "outsourcing" encryption to a non-native CPU. (By the way, I'm not sure that an encryption engine outside the QL would automatically lead to the development of an email client which can handle it.)


The ESP32 negotiates SSL automatically and transparently, so this is an unnecessary complication. Also, it has two CPUs and some memory, so it has the capability to also run a small webserver on your behalf. It can do things like convert image formats, but will just pass through more complex things like javascript, etc.

I appreciate the QL will never support a functional browser for all of today's net. However, you may recall a couple of years ago I was suggesting we develop a "cloud service" for QLers for file exchange, etc. I pictured both positives and negatives of this.

Each QLWiFi has a unique and owner-resettable MAC address. This could be used to identify any particular unit. The service could allow people to register a public and private profile with a server which could then allow users to find each other, have world/user/self FTP boxes (aka open/public, private between two people, and private to self). It would also enable multi-player gaming/data streaming, server side format conversion... The list isn't endless, but would be open to any method of getting a QL online.

The main reasons I wouldn't want to do this are my lack of trust of cloud services, and I wouldn't want to be responsible for the safety and security of other people's data.


User avatar
Peter
Aurora
Posts: 899
Joined: Sat Jan 22, 2011 8:47 am

Re: Internet and the QL

Postby Peter » Mon May 20, 2019 6:58 pm

Dave wrote:
Peter wrote:I wonder if a pragmatic approach, like finding or hosting classic email servers, could help without "outsourcing" encryption to a non-native CPU. (By the way, I'm not sure that an encryption engine outside the QL would automatically lead to the development of an email client which can handle it.)

The ESP32 negotiates SSL automatically and transparently, so this is an unnecessary complication.

But it does not contain the QL-side email client, which is where the procedures of communication with the server need to be handled, and where the ESP32 functions would need to be attached. The QL-side software for that does not automatically exist, just because there is a piece of ESP32 hardware.

Dave wrote:Also, it has two CPUs and some memory, so it has the capability to also run a small webserver on your behalf.

But the ESP32 can not access the QL filesystem. While a solution like QLwIP provides a QL-side webserver on the QL-side filesystem, even for HTTP upload. (I still see filesystem related performance problems on the Q68 which I hope to improve with Wolfgang's help someday, but those would hardly be any better with ESP32 over 8 bit bus.)


User avatar
Dave
SandySuperQDave
Posts: 2417
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Internet and the QL

Postby Dave » Tue May 21, 2019 12:04 am

Peter wrote:But it does not contain the QL-side email client, which is where the procedures of communication with the server need to be handled, and where the ESP32 functions would need to be attached. The QL-side software for that does not automatically exist, just because there is a piece of ESP32 hardware.

*grins* I say nothing. I am not mentioning support for HTML or plaintext formatting, and I'm definitely not mentioning MIME64 support. At all.
Peter wrote:But the ESP32 can not access the QL filesystem. While a solution like QLwIP provides a QL-side webserver on the QL-side filesystem, even for HTTP upload. (I still see filesystem related performance problems on the Q68 which I hope to improve with Wolfgang's help someday, but those would hardly be any better with ESP32 over 8 bit bus.)

The ESP32-based QLWiFi has an onboard FAT32 formatted SD card. It's not anything even close to the performance of QLSD and never will be. It is intended to act as a buffer/store for large downloads. You could have it transfer a QLSD image from another location transparently in the background, or while the QL was off if the QLWiFi is still powered. It's just nice to stack 20 large downloads and go to bed and they're downloaded in the morning. If the QL is left on, they files can be transferred over the QL serial link to QLSD or other storage slowly over time.

Also, NTP time (can automatically set/correct QL clock), local storage for system variables/settings/backups, encryption engine can be used locally (for passwords?), and if the ROM area were DPRAM, it could even install an OS into it then reset the CPU. So many options.

The serial card will increase the speed of that "up to" 100x.



Who is online

Users browsing this forum: No registered users and 6 guests