johnan@ism.isc.com (John Antypas) (12/07/90)
Some of us here at ISC are looking into developing a new interface
for the famous KA9Q program under Unix. While KA9Q works under Unix,
it is a monolithic program handling all client and server tasks.
We would like to split this apart such that clients and servers need
not run as the same process.
To do this, we envision something like:
Clients....Clients...Clients....
\------|--------/-----\
Networking Layer------Scheduling Layer
| |
O/S Specific Interface Layer
The above approach would allow to develop clients and servers to use
a specific set of networking and OS call and not worry about whether
we're running AX.25, TCP/IP, SNA/LU6.2 et al. on Unix, DOS, WIN 3, AmigaDos
et al.
First question:
What should a multi-processing interface library allow access to?
Process creation, destruction, task prioritizing etc...
What should a networking layer handle?
Set up, Teardown, vc byte streams, datagrams et al.
Comments as always, are welcome...
John Antypas / Interactive Systems Corp. .!uunet!ism!johnan johnan@ism.isc.com
All statements belong to author.
"Help! I've crashed -- and I can't reboot!!" -- oracle@iuvax.cs.indiana.edupcg@cs.aber.ac.uk (Piercarlo Grandi) (12/17/90)
On 6 Dec 90 21:26:13 GMT, johnan@ism.isc.com (John Antypas) said: In article <1990Dec06.212613.25912@ism.isc.com> johnan@ism.isc.com (John Antypas) writes: johnan> Some of us here at ISC are looking into developing a new johnan> interface for the famous KA9Q program under Unix. While KA9Q johnan> works under Unix, it is a monolithic program handling all client johnan> and server tasks. We would like to split this apart such that johnan> clients and servers need not run as the same process. What you want to do is essentially a network server like Mach, or user implemented domains like 4.2BSD (not yet implemented). Your network server is a (possibly multithreaded) process that takes "messages" from local processes, packs them up, and then accesses the hardware interface to send them over a particular medium (or viceversa of course). To do it under Unix it is almost essential to have the ability to pass file descriptors in "messages", and to poll()/select() (the latter to simulate multithreading within the server). STREAMS does offer you these abilities, and so does UNIX domain IPC. I'd rather go with STREAMS on System V, even if you have a socket library. I would go with a clone of the AT&T TLI as the API. When you try to open a connection, you must specify a transport provider; the library would then open a well known named stream to the KA9Q server (instead of linking to a multiplexor in the kernel and pushing modules therein), ask it to create an appropriate connection, associate it a file descriptor, and then return over the well known named stream that file descriptor. I think this can be easily implemented also under monotasking OSes; transferring the file descriptor/handle from the "server" to the "client" would just involve an assignment... If you want extra details, read the Accent IPC TechReps from Carnegie Mellon, and the Mach documentation on network servers. If one is prepared to be clever (hacking the Unix scheduler a bit would help), the cost of two context switches on every transaction can be duly minimized. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
louie@sayshell.umd.edu (Louis A. Mamakos) (12/18/90)
In article <PCG.90Dec16234627@teachb.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >What you want to do is essentially a network server like Mach, or user >implemented domains like 4.2BSD (not yet implemented). Your network >server is a (possibly multithreaded) process that takes "messages" from ^^^^^^^^^^^ >local processes, packs them up, and then accesses the hardware interface >to send them over a particular medium (or viceversa of course). Be very careful here. The KA9Q NOS software assumes that each of the tasks are run to completion, and are *NOT* timesliced. When I did the port of the NOS code to the Amiga, I investigated scrapping much of the tasking package used in NOS, and using native Amiga processes (after all, it is a multi tasking operating system on the Amiga). The problem is that there are not synchronization primitives to protect against a NOS task being interrupted before it voluntarily gives up control. In the end, I continued to use the NOS tasker, and just ran it all as one Amiga process. louie WA3YMH
ssb@quest.UUCP (Scott Sheldon Bertilson) (12/28/90)
I've hacked a little on a version of NOS that Anders Klemets ported to System V UNIX. It uses shared memory and semaphores. Each application runs in a separate process and uses a simulated socket library to communicate with the server process. I don't think Anders sees it as anything more than an experiment because the overhead of synchronization using semaphores does a good job of gobbling up substantially more than a 10 MHz 68010 (my AT&T 3B1). I made a change to interlock using a test-and-set instruction on some shared memory before trying to get a major semaphore..it increased the efficiency of the package enough so that it is reasonably snappy, but I've had problems with synchronization not working properly, so I can't call it a success. -- Scott S. Bertilson ...ssb@quest.UUCP scott@poincare.geom.umn.edu
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <1990Dec28.021435.11795@quest.UUCP> by ssb@quest.UUCP (Scott Sheldon Bertilson): +--------------- | I've hacked a little on a version of NOS that Anders Klemets ported | to System V UNIX. It uses shared memory and semaphores. Each > ... | overhead of synchronization using semaphores does a good job of | gobbling up substantially more than a 10 MHz 68010 (my AT&T 3B1). | I made a change to interlock using a test-and-set instruction | on some shared memory before trying to get a major semaphore..it | increased the efficiency of the package enough so that it | is reasonably snappy, but I've had problems with synchronization | not working properly, so I can't call it a success. +--------------- I'm working on a complete reimplementation using Streams for SVR3. It is based on raw Streams, not the NSL, so it should work on any System V that has Streams support --- and some that claim not to, like Xenix 2.3.x without the appropriate network package. (I'm doing this under Xenix 2.3.3.) Of course, this won't help on a 3B1, which is SVR1 in the kernel. (Actually, I'm still trying to decide how much I should do at the Streams level --- should I simply arrange for local sockets and use ordinary programs to do the real work, or put AX.25, NET/ROM, and TCP/IP in Streams modules and have the far end be selectable between a "bidirectional Streams pipe" and a real Streams tty driver? The problem with the latter is that it isn't particularly easy to implement something like NOS's "ax25 route add" command.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY