• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

emate Webserver

beachycove

Well-known member
A first shot only, and as yet without WoL, but check it out and leave me a message under the "Message Pad" Tab:

It is not über-stable, but that seems to be the NPDS way. It reboots automatically, however, so in that sense it's maintenance-free.

I will post some configuration details sometime soon.

 

beachycove

Well-known member
Serving an image from NPDS is not especially easy. Though it can be done, I think the thing is already basically on one of two speeds: slow or dead stop. Best just to keep it slow.

I could host an image elsewhere and link to it, of course, but that doesn't seem like fair play. At the moment, everything is in the eMate as html 4, css, and a couple of scripts. That seems better to me.

I have been playing tonight with a trial WakeOnLan script, but no luck there as yet.

 

beachycove

Well-known member
Still testing, but the unna trackers will hopefully get sight of the thing in due course -- assuming I can get the tracker working. My initial attempts to use the tracker pkg failed.

 

uniserver

Well-known member
why does it seem like there is a small delay, then it kicks up the page, could that just be a router firewall thing? i tried to ping it, no dice.

 

beachycove

Well-known member
No idea about the ping; that should work as it is just a fixed ip, and the router hasn't been down afaik. The speed also shouldn't be the fault of the router, as I have at times had pages served from other machines, and they have been zippy enough for a household connection. It's also just as slow when I connect through its 192.xxx ip address, as opposed to the public ip, so I don't think it's a networking issue in the sense of external routing complications.

The trouble has to be in the platform, software and hardware. I am not sure what NPDS has to do to serve webpages as all, but presumably there would have to be Newtonscripts running that direct a Note not to the screen, but to ethernet and to you as the endpoint, which is not actually supposed to be happening at all in the NewtonOS (thus, e.g., in NPDS the screen does not change when pages are served, apart from reporting hits). Presumably, therefore, NPDS is doing something funny at the routing level through Newtonscript. You have to remember too that NIE (Newton Internet Enabler) itself was designed for modems rather than later networking standards. So much of what is happening at NIE level in the machine is based on this and that later hack, and how good the hacks in question were is anyone's guess. They are not, however, the work of Walter Smith and co., inc.

NPDS itself could be optimized further, as it is open source, but development stopped dead about a decade ago and was only ever the work of one man, I believe. It crashes several times a day, usually (but mostly auto-recovers). So it is an interesting, but limited piece of software that suffers from the usual problems that we have with open source ideals in the vintage Mac community: many and perhaps most of us never learned to code (presumably since we didn't like nasty command lines and the barrenness of text editors, which were for the 'dark side').

The other thing is the hardware. Even the much faster Newton 2100 is slow serving pages, like the (probable) best of the bunch here, and my page is running on a much less capable eMate -- albeit an eMate with the Newertech memory upgrade (which makes a big difference to the usefulness of the machine).

Now, my pages use custom css for the most part (albeit very simple) rather than (mostly) the built-in css. That may be slowing it down, or maybe not. I did test first with the built-in css, and I didn't notice it as being any faster than it was later with my own code. I did not try with absolutely Spartan code, but that would make an interesting experiment.

Still, stability issues and slowness and all aside, it is an interesting device to tinker with in this way if you happen to have one lying around. Your posts are simply Notes written in the NotePad and filed in a designated web folder. There is a little html, and there are a handful of NPDS naming conventions, but there's not much to it. So it would lend itself well to a sort of vintage blogging.

Which reminds me — I ought to make another couple of posts to keep it rolling.

 

uniserver

Well-known member
kingmac1:~ apple$ ping 69.196.165.253

PING 69.196.165.253 (69.196.165.253): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

Request timeout for icmp_seq 3

Request timeout for icmp_seq 4

Request timeout for icmp_seq 5

Request timeout for icmp_seq 6

Request timeout for icmp_seq 7

Request timeout for icmp_seq 8

Request timeout for icmp_seq 9

^C

--- 69.196.165.253 ping statistics ---

11 packets transmitted, 0 packets received, 100.0% packet loss

kingmac1:~ apple$ traceroute 69.196.165.253

traceroute to 69.196.165.253 (69.196.165.253), 64 hops max, 52 byte packets

1 dsldevice (192.168.1.254) 1.131 ms 0.685 ms 0.552 ms

2 76-217-168-2.lightspeed.livnmi.sbcglobal.net (76.217.168.2) 23.476 ms 19.532 ms 18.929 ms

3 * * *

4 * * *

5 * * *

6 12.83.32.169 (12.83.32.169) 24.161 ms

12.83.32.129 (12.83.32.129) 22.909 ms 21.514 ms

7 gar13.cgcil.ip.att.net (12.122.133.121) 28.485 ms 40.399 ms 28.384 ms

8 * * *

9 tge1-4.fr4.yyz.llnw.net (69.28.172.70) 43.773 ms

tge8-4.fr4.yyz.llnw.net (69.28.189.138) 48.085 ms

tge1-4.fr4.yyz.llnw.net (69.28.172.70) 51.420 ms

10 teksavvy.tge6-2.fr3.yyz.llnw.net (208.111.182.142) 44.737 ms 44.305 ms 45.128 ms

11 2120.tengigabitethernet-1-0-0.lns01.tor.packetflow.ca (69.196.136.79) 43.782 ms 47.394 ms 45.704 ms

12 * * *

13 * * *

14 * * *

15 * * *

16 * * *

17 * * *

18 * * *

19 * * *

20 * * *

21 * * *

22 * * *

23 * * *

24 * * *

25 * * *

26 * * *

27 * * *

28 * * *

29 * * *

30 * * *

 

uniserver

Well-known member
ah yes works good now :)

64 bytes from 69.196.165.253: icmp_seq=15 ttl=51 time=69.752 ms

64 bytes from 69.196.165.253: icmp_seq=16 ttl=51 time=57.228 ms

64 bytes from 69.196.165.253: icmp_seq=17 ttl=51 time=52.998 ms

64 bytes from 69.196.165.253: icmp_seq=18 ttl=51 time=63.164 ms

64 bytes from 69.196.165.253: icmp_seq=19 ttl=51 time=56.322 ms

64 bytes from 69.196.165.253: icmp_seq=20 ttl=51 time=55.003 ms

64 bytes from 69.196.165.253: icmp_seq=21 ttl=51 time=56.707 ms

64 bytes from 69.196.165.253: icmp_seq=22 ttl=51 time=72.208 ms

64 bytes from 69.196.165.253: icmp_seq=23 ttl=51 time=53.852 ms

64 bytes from 69.196.165.253: icmp_seq=24 ttl=51 time=55.262 ms

64 bytes from 69.196.165.253: icmp_seq=25 ttl=51 time=55.730 ms

64 bytes from 69.196.165.253: icmp_seq=26 ttl=51 time=55.666 ms

64 bytes from 69.196.165.253: icmp_seq=27 ttl=51 time=56.884 ms

64 bytes from 69.196.165.253: icmp_seq=28 ttl=51 time=76.495 ms

64 bytes from 69.196.165.253: icmp_seq=29 ttl=51 time=55.260 ms

64 bytes from 69.196.165.253: icmp_seq=30 ttl=51 time=54.453 ms

64 bytes from 69.196.165.253: icmp_seq=31 ttl=51 time=56.154 ms

64 bytes from 69.196.165.253: icmp_seq=32 ttl=51 time=57.820 ms

 
Top