lenny@icus.islp.ny.us (Lenny Tropiano) (10/15/89)
As most of the readers of these groups know, I just got myself two STARLAN
NAU boards. I was having some problems with configuration of the HDB
files (Devices, Dialers, etc..) because my installation script didn't
adjust to my own files here. Thanks to a few people who replied to my
"plea" for help (since I had no manuals -- and didn't want to spend hours
trying figure out something that was a matter of changing one line...).
Well after some more investigation, I noticed why my uucico didn't want
to dial out using the starlan device. What happened I had a special
version of HDB here that didn't have the starlan calls (starlan library)
compiled with it. It was trying to open up /dev/starlan and just
send stuff to it, expecting login: in return. That obviously didn't work.
Some comments about STARLAN connections, they are real fast. It's nice
to be able to "cu" to my machine (which previously just had one 19.2K
RS232 connection between it). And then do uucp transfers at the same
time (in either direction) as well as "cu" again, or "cu" the other
way, all simultaneously ... The degradation in speed is negligible,
but the load on both machines in my small network were pretty minimal.
Thad Floryan (and others) will be able to tell us how things work when
there is more than one STARLAN node connected in daisy-chain fashion.
I'd like to hear if anyone actually has a *star* configuration using
the STARLAN NEU (Network Extension Unit) [the Universities might
do it this way...]
Establishing a network connection using "cu" does take some time
to sync up and actually connect to the remote site. I wonder why
this is the case, uucico's start up real fast. I think because the
"sl" (starlan login) service has to handle "pty" type devices called
"psx" it might take a few seconds (almost 30) to get connected.
I don't know how the Asynchronous Emulator (from the Phone Manager) works
because I keep getting this:
+--------------------------------------------+
| Error |
| Profiles |
| /u/lenny/Filecabinet/Profiles/-1 not |
| found in Filecabinet/Profiles |
| |
+--------------------------------------------+
My device is set up as "STARLAN", with the data profile as STARLAN.
-rw-rw---- 1 lenny icus 844 Oct 11 18:37 Profiles/STARLAN:Sl
Well so much for that, I'm sure I'll figure it out, or at least have
someone tell me what to do... ;-)
Ok, a little benchmarking ... The uucp protocol by default for STARLAN
connections is the "e-protocol" (error free data path). I would assume
there is no, or very little, handshaking done here. The data path is
assumed to be error free, and 1024 packets are shoveled down the line to
the remote node.
I needed a *big* file to test this with... A fairly large one was my
news history file ...
-rw-r--r-- 1 news news 2352055 Oct 14 23:27 /usr/lib/news/history
Using the "e-protocol" this file went to my other machine, icusdvlp over
STARLAN this fast!
icusdvlp!root M (10/15-0:24:58) (C,2252,1) [starlan] -> 2352055 / 78.550 secs,
29943 bytes/sec
Yes, 78 seconds over 2MB of file... Yes, and at 29943 bytes per second!
That's bytes per second! I get about 1100 bytes per second on the average
for a 19.2K Telebit Trailblazer connection!
Then I switched to the "g-protocol" using a WINDOWS=7 uucico, and still
using STARLAN transport medium.
icusdvlp!root M (10/15-0:43:48) (C,2268,1) [starlan] -> 2352055 / 1045.800 secs,
2249 bytes/sec
This took, about 17 minutes, quite a bit of a change. Now you see how
much overhead the g-protocol uses. But still here it's twice as fast
as my Telebit (and that's fast), and still faster than the 19.2K direct
RS-232 connection, which was ~32 minutes (at WINDOWS=7)
icusdvlp!root M (10/15-1:14:48) (C,2273,1) [tty000] -> 2352055 / 1942.834 secs,
1211 bytes/sec
So I guess it's probably good to say that 78 seconds vs. 32 minutes is quite
an improvement!
Now what's in store for the future of my STARLAN. Well I'd like to write
my own server. Maybe implement TCP/IP over the STARLAN ... I'd like to
write a better "cu" for the thing, it's too slow to connect. Sending
character by character isn't good either. Adding new services seems
simple (even though I don't have a manual). Each service looks like it
has an unique number, located in the /usr/net/nls/starlan/dbf file:
1:na:NULL,:/usr/net/servers/sl # Remote login
102:n:NULL,:/usr/net/servers/uucplogin # Mail/File transfer
(This case it's 1 and 102). I could easily add another program, to
do TCP/IP connections...
Well I babbled on for long enough ... Take it easy all.
-Lenny
--
| Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 |
| lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 |
| {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny |
+------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+stevens@hsi.UUCP (Richard Stevens) (10/15/89)
Can anyone provide a quick description of what the programming
interface to the Starlan system looks like on the 3b1 ??
Is it in any way similar to TLI ??
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.com
... { uunet | yale } ! hsi ! stevenslenny@icus.islp.ny.us (Lenny Tropiano) (10/16/89)
In article <693@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: |>Can anyone provide a quick description of what the programming |>interface to the Starlan system looks like on the 3b1 ?? |>Is it in any way similar to TLI ?? |> |> Richard Stevens |> Health Systems International, New Haven, CT |> stevens@hsi.com |> ... { uunet | yale } ! hsi ! stevens Well I don't have my STARLAN programmers manuals yet, but from what I see, it is TLI, or a derivative thereof. $ ls -ls /usr/lib/net/* total 128 1 -r--r--r-- 1 bin bin 28 Oct 9 00:36 libnls.a 1 -r--r--r-- 1 bin bin 28 Oct 9 00:36 libnsl_s.a 115 -r--r--r-- 1 bin bin 58626 Oct 9 00:36 libslan.a 6 -r--r--r-- 1 bin bin 3040 Oct 9 00:36 llib-lslan 5 -r--r--r-- 1 bin bin 2332 Oct 9 00:36 llib-lslan.ln $ ar tv /usr/lib/net/libslan.a rwxr-xr-x 103/ 100 476 Jul 30 18:31 1986 discstr.o rwxr-xr-x 103/ 100 430 Jul 30 18:31 1986 drain_out.o rwxr-xr-x 103/ 100 1256 Jul 30 18:31 1986 fdswap.o rwxr-xr-x 103/ 100 1328 Jul 30 18:31 1986 t_accept.o rwxr-xr-x 103/ 100 1368 Jul 30 18:31 1986 t_listen.o rwxr-xr-x 103/ 100 978 Jul 30 18:31 1986 t_look.o rwxr-xr-x 103/ 100 766 Jul 30 18:32 1986 t_rcvcon.o rwxr-xr-x 103/ 100 1154 Jul 30 18:32 1986 t_rcvdis.o rwxr-xr-x 103/ 100 394 Jul 30 18:32 1986 t_rcvrel.o rwxr-xr-x 103/ 100 1674 Jul 30 18:32 1986 t_rcvudata.o rwxr-xr-x 103/ 100 656 Jul 30 18:32 1986 t_rcvuderr.o rwxr-xr-x 103/ 100 1240 Jul 30 18:32 1986 t_snddis.o rwxr-xr-x 103/ 100 394 Jul 30 18:32 1986 t_sndrel.o rwxr-xr-x 103/ 100 1410 Jul 30 18:32 1986 t_sndudata.o rwxr-xr-x 103/ 100 2094 Jul 30 18:32 1986 t_sync.o rwxr-xr-x 103/ 100 512 Jul 30 18:31 1986 t_getstate.o rwxr-xr-x 103/ 100 2336 Jul 30 18:31 1986 t_dump.o rwxr-xr-x 103/ 100 2136 Jul 30 18:32 1986 nlsconnect.o rwxr-xr-x 103/ 100 1196 Jul 30 18:32 1986 nlsaddr.o rwxr-xr-x 103/ 100 510 Jul 30 18:31 1986 t_getinfo.o rwxr-xr-x 103/ 100 1050 Jul 30 18:32 1986 nlsenv.o rwxr-xr-x 103/ 100 1964 Jul 30 18:32 1986 nlsestab.o rwxr-xr-x 103/ 100 538 Jul 30 18:31 1986 t_bind.o rwxr-xr-x 103/ 100 854 Jul 30 18:31 1986 t_connect.o rwxr-xr-x 103/ 100 690 Jul 30 18:31 1986 t_free.o rwxr-xr-x 103/ 100 970 Jul 30 18:31 1986 t_open.o rwxr-xr-x 103/ 100 1916 Jul 30 18:31 1986 t_connutil.o rwxr-xr-x 103/ 100 3702 Jul 30 18:31 1986 t_optmgmt.o rwxr-xr-x 103/ 100 1758 Jul 30 18:31 1986 t_alloc.o rwxr-xr-x 103/ 100 630 Jul 30 18:31 1986 t_close.o rwxr-xr-x 103/ 100 672 Jul 30 18:32 1986 t_unbind.o rwxr-xr-x 103/ 100 848 Jul 30 18:32 1986 nlsname.o rwxr-xr-x 103/ 100 1694 Jul 30 18:32 1986 nlsrequest.o rwxr-xr-x 103/ 100 974 Jul 30 18:31 1986 t_error.o rwxr-xr-x 103/ 100 1240 Jul 30 18:31 1986 t_errlst.o rwxr-xr-x 103/ 100 930 Jul 30 18:32 1986 t_rcv.o rwxr-xr-x 103/ 100 848 Jul 30 18:32 1986 t_snd.o rwxr-xr-x 103/ 100 7632 Jul 30 18:32 1986 t_utility.o rwxr-xr-x 103/ 100 2560 Jul 30 18:31 1986 t_data.o rwxr-xr-x 103/ 100 600 Jul 30 18:31 1986 lname2addr.o rwxr-xr-x 103/ 100 1020 Jul 30 18:31 1986 net_ioctl.o rwxr-xr-x 103/ 100 366 Jul 30 18:32 1986 nlsdata.o rw-r--r-- 103/ 100 350 Jul 30 18:30 1986 mark.o The routines are a STREAMS-like interface to the network. I've seen them documented t_bind(), t_connect() in the network section of the 386 in section 3N. -Lenny -- | Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 | | lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 | | {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny | +------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+
doug@marque.mu.edu (10/16/89)
In article <983@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >In article <693@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >|>Can anyone provide a quick description of what the programming >|>interface to the Starlan system looks like on the 3b1 ?? >|>Is it in any way similar to TLI ?? >|> >|> Richard Stevens >|> Health Systems International, New Haven, CT >|> stevens@hsi.com >|> ... { uunet | yale } ! hsi ! stevens > >Well I don't have my STARLAN programmers manuals yet, but from >what I see, it is TLI, or a derivative thereof. > ... >The routines are a STREAMS-like interface to the network. I've seen >them documented t_bind(), t_connect() in the network section of >the 386 in section 3N. The 3B1/Starlan routines are TLI. Once upon a time they were documented in AT&T manuals, along with the DOS version, compatible with NetBios, and the 3B2 version, which is actually a real STREAMS version. In particular there was an "Application Programmer's Reference Manual", order code 999-802-215IS, and a "Starlan Network Tecnnical Reference Manual", order code 999-300-208IS. These manuals explain (;--) the NAU/NRU/NEU construction for 3B2/3B1/DOS, and document (;;-) the low level protocol, which is URP (Yeh:-good choice for a name, AT&T calls it Universal Receiver Protocol) at the network level, and NetBios like naming conventions above the transport level. With apologies for the commercial, some of this is explained in the recent Howard Sams Unix library book "Unix Networking", which has chapers by me on STREAMS, TLI, and RFS (along with UUCP by Brian Redman, TCP by Doug Comer, NFS/RPC by Louis Delzompo, Lan Manager by Martin Dunsmuir, X Windows by Adrian Nye, and NEWS by Owen Densmore). The TLI chapter materials were developed initially on 3B1 (actually 7300), there is sample code, and explanations of some of the mysteries. I'll post the sample code shortly, after digging it out and making sure it compiles :--. We run the oclient/srvo, iclient/srvi code given in the book here, with Starlans in two separate buildings,, and a 3B2/310 on each Starlan as a server. The 3B2s also have Ethernet but there is no bridge (we just use UUCP as a bridge for mail and file transfer). The programs are primitive, therefore I can almost understand them and fix them if they have a problem. Bells and Whistles can be added to taste. Douglas Harris doug@marque.mu.edu uunet!marque!doug