Closed masinter closed 1 year ago
At the moment, we have access to the (raw ethernet) network only on a Solaris system. In order to demonstrate network access on other systems we should look to the Berkeley Packet Filter interface, rather then the DLPI or NIT interfaces that are/were available on SunOS/Solaris.
Where is the TCP/IP source code located?
@tuexen -- The Lisp implementation of TCP/IP was deleted from the repo -- better to use the underlying OS implementation for anything we can, I think. For PUP and XNS we have to use the Lisp implementation and the underlying OS raw ethernet interface (e.g., the /dev/bpf)
@tuexen -- In the medley repo: % git whatchanged | grep TCP
@nbriggs Thanks for the information. I was looking for the TCP code and did not find it... I have not idea what PUP and XNS is, I was just wondering if there is interest in using the TCP stack from the Lisp code base. I'm somewhat familiar with TCP and have an interest in Lisp. So I was wondering if there is interest in getting the old codebase to work... But using the host stack gives you a much more modern TCP implementation...
Thanks for the quick response!
@tuexen -- PUP => PARC Universal Packet, the packets on the original 3 Mb ethernet (http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-10_Pup_An_Internetwork_Architecture_Jul79.pdf), and XNS => Xerox Network Services, the packets on the 10 Mb ethernet. Novell Netware copied the XNS Internet Datagram Protocol (IDP) for their IPX protocol. The old Lisp TCP/IP implementations were deprecated by the original maintainers after Interlisp started to be run on the emulator. On the original D-machines Interlisp was the OS, and had to implement everything including the raw ethernet packet handling, the page fault handlers, the disk controller operations, the file system etc., ... It became a lot easier to maintain when that could all be delegated to the OS.
It followed pretty closely the design of the BSD stack from the early ‘80s, but implemented in Interlisp-D to work on 10-Mb Ethernet. With the transition to non-Xerox hardware the decision was made to use the stack provided by the host OS since the support and improvements would come from those OS maintainers. TCP/IP’s come a pretty long way since then and I wouldn’t be surprised if there aren’t some incompatibilities against current stacks.
On Dec 25, 2021, at 3:25 PM, Michael Tüxen @.***> wrote:
@nbriggs https://github.com/nbriggs Thanks for the information. I was looking for the TCP code and did not find it... I have not idea what PUP and XNS is, I was just wondering if there is interest in using the TCP stack from the Lisp code base. I'm somewhat familiar with TCP and have an interesting in Lisp. So I was wondering if there is interest in getting the old codebase to work... But using the host stack gives you a much more modern TCP implementation...
Thanks for the quick response!
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/573#issuecomment-1001078856, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBP2DFZQNP6X5KKJHZYZSTUSZAERANCNFSM5IITCKUQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.
It followed pretty closely the design of the BSD stack from the early ‘80s, but implemented in Interlisp-D to work on 10-Mb Ethernet. With the transition to non-Xerox hardware the decision was made to use the stack provided by the host OS since the support and improvements would come from those OS maintainers. TCP/IP’s come a pretty long way since then and I wouldn’t be surprised if there aren’t some incompatibilities against current stacks.
That is what I'm interested in. I'm working on today's TCP stack of FreeBSD and would expect that it can interoperate with a stack just doing the initial specification (RFC 793)...
@tuexen -- PUP => PARC Universal Packet, the packets on the original 3 Mb ethernet (http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-10_Pup_An_Internetwork_Architecture_Jul79.pdf), and XNS => Xerox Network Services, the packets on the 10 Mb ethernet. Novell Netware copied the XNS Internet Datagram Protocol (IDP) for their IPX protocol. The old Lisp TCP/IP implementations were deprecated by the original maintainers after Interlisp started to be run on the emulator. On the original D-machines Interlisp was the OS, and had to implement everything including the raw ethernet packet handling, the page fault handlers, the disk controller operations, the file system etc., ... It became a lot easier to maintain when that could all be delegated to the OS.
Thanks for the clarification. Unfortunately, I have no experience with PUP and XNS. My interest would have been the TCP stack in lisp...
You're more than welcome to check out the old code that you'll find from the git whatchanged command I mentioned above. I am looking to get the BPF interface for raw ethernet packets working, and that should allow the Lisp TCP/IP code to run again.
You're more than welcome to check out the old code that you'll find from the git whatchanged command I mentioned above. I am looking to get the BPF interface for raw ethernet packets working, and that should allow the Lisp TCP/IP code to run again.
That should work... You have to make sure that the host stack does not interfere with the stack in the Lisp VM. Drop me a note once it is finished or if you have questions related to this...
you might want to check in the interlisp/history repository; the TCP files were moved to library/Obsolete/ by 2016. history-tcp-files.txt There might be some possibility of running Medley 2 on DOS, but the state of emulating old network cards in FreeDOS or DosBox is probably a problem.
What I remember was that trying to implement a full TCP protocol stack by reading RFCs was a learning experience. The XNS and PUP documents were a lot clearer (or maybe the implementors were down the hall).
The work on "dodo" (XNS in Java) noted above might provide an opportunity to revive Medley networking?
This issue has more useful information than #456 so I'll mark that one duplicate and close it.
Hello,
the branch dodo-nethub-support
in my clone of Maiko
has a version of Maiko allowing to connect directly to a Dodo Nethub for
using Dodo XNS services.
(for details about building and usage
see Using Dodo-networking with Maiko)
The Dodo Nethub support was implemented and tested with x86_64-Linux, so the following information and tour through a demo apply to this platform.
The file dodo-and-medley.zip
attached to this post contains the following items:
dodo-demo.tgz
: this is a demo Dodo setup (see below)run-medley
: a version of the standard script from the Medley site,
adapted for the additional options of the Dodo-networking capable Maikojob_0183_7090_DD36.pdf
: a sample PDF of a .tedit
-file loaded
from the medley file service in the Dodo-demo opened through the FileBrowser
with See and printed from MedleyUnpacking the dodo-demo.tgz
archive creates a directory dodo-demo
with
a prepared Dodo setup, based on the standard Dodo distribution with an additional
file service medley having the file drawer internal holding some documentation
files taken from the subdirectory docs/internal
of the Medley github project.
The print service poseidon is prepared to produce PDF files with support for
standard Xerox fonts (Classic, Modern fonts).
Remark: producing PDF for printouts requires that the program ps2pdf
is available
through the shell PATH
, so make sure that Ghostcript is installed on your system
and the PATH
environment variable is set up accordingly.
For running the Dodo demo system, open 2 shells, change to the dodo-demo
directory
in each and:
./run-nethub.sh
./run-dodoserver.sh
For shutting down the Dodo demo system, simply stop the programs with Ctrl-C in reverse order.
The Medley environment i used for my experiments was the release medley-211122
(loadups
and runtime, downloaded 2021-11-24), using the full sysout. Newer releases also worked
but were not my "daily" test environment. In any cases, XNS networking must be initialized
by running the function \NSINIT
when a fresh "loadup" sysout is started resp. XNS networking
was not used so far (without \NSINIT
Lisp will try forever to reach a Clearinghouse).
For a quick tour through the combined Medley/Dodo demo environment:
run-medley
script and connecting to the Dodo Nehub
with:run-medley -nh-host localhost
-nocroll
)And then in the Lisp environment:
if not already done or perviously saved with the image: initialize XNS networking by
(\NSINIT)
thereopen a FileBrowser through the background context menu and let it open the following
target directory:
{medley:}<internal>
a prompt window requesting to login should open, enter the user motu
and the password
master
the FileBrowser should now list the files of the above directory and allow the usual operations there (see, recompute etc.)
to view a document, select a .tedit
file in the list
attention: for some documents, the content cannot be displayed due to some missing Lisp function,
so possibly close the TEdit window and choose a different document
use the printer poseidon:
(note the colon!) for printing, the print results will be created
in the subdirectory dodo-demo/prt-poseidon
by the Dodo print service (.ip
,
.interpress
, .ps
, .ps.log
and (if ps2pdf
is present) .pdf
files);
printing was tested with the Hardcopy > To a printer function (background context menu) and with TEdit
for .tedit
files (including embedded bitmap- and Sketch-images)
Experienced Interlisp-D users probably know more use-cases for using XNS services, the above were my standard tests for extending Dodo to support the little Medley-specialities at XNS filing and printing level.
Greetings
Hans
Attachment: dodo-and-medley.zip
Astounding!
Hello,
looking again at the file i uploaded yesterday, i've seen that the filenames in the archive were messed up...
So please rename the files after unpacking as follows to match the names mentioned in my previous post:
from: | to: |
---|---|
dodo-demo.TGZ | dodo-demo.tgz |
dodo-demo.sh | run-medley |
dodo-demo.pdf | job_0183_7090_DD36.pdf |
(Github does not accept all extensions for file uploads to a post, e.g. insisted on an uppercase .tgz
extension and run-medley
(or run-medley.sh
) was simply rejected; so before putting them into a single ZIP-archive, i wanted to rename the .TGZ
back to lower case: that's when scrambling the filenames must have happened, as it seems i had all 3 files selected when renaming with the Windows10-Explorer, which fired this super-Windows feature where all 3 got the same name and the .TGZ
extension kept being upper case)
Sorry for the inconvenience Hans
Success!
I'm not sure what I did differently -- I was dying with a stack overflow trying to CH.FINDSERVER -- but today, after several similar failures, it all worked!
demoing CoLab and things like it (didn't Notecards have some networking possibilities?) maybe TELERAID?
Congratulations!
Yes, i also had stack overflows with some of the fresh loadup images, but others worked fine. Not sure if some of the failing ones have less things preloaded and one crucial thing is missing.
The important thing is to call \NSINIT
first! Can this be included in the loadup generation so this can't be forgotten?
BTW: is there a mail client in Interlisp to check if exchanging mails with Star or Viewpoint works?
Hans
Larry can look back at how the network initialization used to work -- he removed the Lisp code that used to get the ethernet properly initialized in order to speed things up when the network wasn't present. It's NOT as simple as calling \NSINIT in the loadup.
Yes, Lafite is the mail client that understands XNS mail (and Grapevine on a PUP network).
Could you rebase onto the current maiko master branch -- all the Addr68k_from_LADDR etc. have been replaced by NativeAligned{2,4}FromLAddr to reduce the compiler warnings for incorrect alignment.
I'm looking at trying to reduce the entropy in the code, and this seems like a good time to look at splitting the ethernet handling code up in to separate files so that you don't have to guess which definition of something is active for which set of #ifdef
options.
just pushed a new Maiko version in my branch:
Addr68k_from_LADDR
are replaced with NativeAligned{2,4}FromLAddr
in ether.c
MAIKO_EMULATE_TIMER_INTERRUPTS
and MAIKO_EMULATE_ASYNC_INTERRUPTS
, with the 2nd implying the 1stplatform.h
, yesterday's definition disappeared from the cygwin makefileMAIKO_TIMER_ASYNC_EMULATION_INSNS_COUNTDOWN
, defaulting to 20.000MAIKO_EMULATE_*
is defined, a new command line parameter can be given as -intr-emu-insns
to specify an override for the interrupt countdown valueCompiles and works on Linux-x86_64 and Cygwin, the new command line option is untested however
ok, that's all for today...
OK, I'll look. It should probably reuse the "-t" flag that is currently (supposed to...) set the timer frequency.
The style for options should be '-x' (or '-xx') for short options or '--longer-option' (double dash). We're going to rationalize the option processing though, so you probably don't need to deal with that.
I'm going to this issue into a Discussion about possible networking goals (for TCP) since it's not clear what the goal is and open an issue to document the 'dodo' networking for PUP and XNS access via emulation
Network: Medley has full protocol stacks, in Lisp, for three families of network protocols: PUP, XNS, and TCP/IP. Can we demonstrate?