Undeliverable mail
PMDF Mail Server
Postmaster%TRINCC.BITNET at mitvma.mit.edu
Sat Jul 9 17:25:06 AEST 1988
The message could not be delivered to:
Addressee: TRIN4
Reason:
%MAIL-E-SYNTAX, error parsing 'DJA1::[TRIN4.BOX1024]'
----------------------------------------
Received: from JNET-DAEMON by TRINCC.BITNET; Mon, 4 Jul 88 04:06 EST
Received: From YALEVM(MAILER) by TRINCC with Jnet id 4462 for TRIN4 at TRINCC;
Mon, 4 Jul 88 04:04 EST
Received: by YALEVM (Mailer X1.24) id 4459; Mon, 04 Jul 88 04:01:18 EST
Date: Wed, 29 Jun 88 02:45:52 EST
From: Mike Muuss The Moderator <Info-Unix-Request at BRL.ARPA>
Subject: INFO-UNIX Digest V5#083
Sender: Info-Unix distribution list <I-UNIX at TCSVM.BITNET>
To: Robert Cummings <TRIN4 at TRINCC.BITNET>
Reply-to: INFO-UNIX at BRL.ARPA
Comments: To: INFO-UNIX at BRL.ARPA
INFO-UNIX Digest Wed, 29 Jun 1988 V5#083
Today's Topics:
Re: Bliss Compiler wanted
Re: bbs for unix based systems
Re: Real-time UNIX - what is it & who has it?
Recommendations wanted for workstations and CASE tools
Re: "cd path" strangeness
Re: RCS and SCCS
Re: HOW DO I MAKE VI'S AUTOINDENT NOT USE TABS?
Shouting the return code. (Re: Meaning of "rc" in cron/log)
Re: how can I "." in csh?
Re: Shouting the return code. (Re: Meaning of "rc" in cron/log)
Re: Is a NEED for more COMMERCIAL usenet feed providers?
Re: AT&T vs. CSS (PC/Tools)
Tabs in VI
SLIP protocol specification
Termcap/Terminfo question
UUCP Over TCP/IP
Re: RCS and SCCS (and CMS)
Getting vi to automagically use macros
-----------------------------------------------------------------
From: Steve Simmons <simmons at applga.uucp>
Subject: Re: Bliss Compiler wanted
Date: 24 Jun 88 14:36:01 GMT
To: info-unix at brl-sem.arpa
In article <315 at gt-eedsp.UUCP> jensen at gt-eedsp.UUCP (P. Allen Jensen) writes:
>
>Is the CMU Bliss the same as the BLISS used by DEC ?
In '83 I was supporting some BLISS-10 utilities at ADP Network Services.
We ran into bugs in the DEC BLISS-10 compiler which DEC wouldn't fix. We
had source, which was full of CMU names. I went to CM to see if theirs
was PD, and if so, could we get it. On doing some comparison, we found
that the DEC BLISS-10 compiler was absolutely identical to the CMU except
for a few bug fixes CMU had done since DEC picked it up.
About this time DEC came out with the BLISS-16, BLISS-32, and BLISS-36
compilers to be their "standard systems development language". They
wanted a ludicrous amount of money for BLISS-36. We ordered an evaluation
copy, and found it was absolutely identical to BLISS-10. Same checksum.
And same support categore. I forget the name, but it meant "We will
accept bug reports. But we will take no action."
That's the way it was in '83.
Needless to say, we didn't buy BLISS-36. If you can get BLISS from CMU
and you have a PDP-10 machine, do it.
--
+- Steve Simmons UNIX Systems Mgr. Schlumberger CAD/CAM -+
+ simmons at applga.uucp ...umix!applga!simmons +
+- "Opinions expressed are all my own, etc, etc, etc, etc, etc, etc, etc." -+
-----------------------------
From: Karl Meiser <koala at ddsw1.uucp>
Subject: Re: bbs for unix based systems
Date: 24 Jun 88 19:41:55 GMT
To: info-unix at brl-sem.arpa
I myself should be suggesting my own work, premature as it is. Currently
i am working on a message system (run from the shell) but it is no where
near complete.
I will however suggest AKCS. Infact, the system i am currently at is
the home of AKCS. This software has linking prgs, etc, so that you can
connect systems together by sending new items back and forth. This
system currently connects 4 systems, and the more the better. For more
information, contact Karl Denniger at (312)566-8909 voice, (312)566-8911
or (312)566-8912 for the system. You can also send mail to ..!ddsw1!karl
--
Karl Meiser ..!att!spl1!ddsw1!koala
I said that?? I musta been sleeping!
-----------------------------
From: Ian Kluft <kluft at hpcupt1.hp.com>
Subject: Re: Real-time UNIX - what is it & who has it?
Date: 24 Jun 88 20:34:30 GMT
To: info-unix at SEM.BRL.MIL
/ adamm at necis.UUCP (Adam Moskowitz) / writes:
> A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like
> operating system".
[ ... ]
> Assuming that you are doing something like data acquisition or
> process control, what is required to make an O/S "real-time"?
>
> The answer he and I came up with was this: the ability to have absolute
> control over the scheduling of processes.
Two issues to note when looking for a real-time OS are
kernel pre-emption
context switching time
Kernel pre-emption is an important one to consider on Unix because most
Unix systems do not allow system calls to be interrupted. Of course,
context-switching time is somewhat obvious because it affects the time
between arrival of an interrupt and (re)starting a user process to handle
the event.
That's really what it comes down to. If a guarantee can be made of the
amount of time it takes between an event and entering the code to handle
it, an OS is considered real-time. Of course, if that time is too long,
it isn't worth mentioning.
[End of unbiased material]
While everyone was mentioning the real-time Unix's they knew of, I thought
I'd mention the one I work with. Hewlett-Packard's HP-UX is a full System
V with extentions for BSD 4.2 and real-time. While I don't have the exact
numbers for measured real-time response, I remember that they are measured
in milliseconds, as would be expected.
------------------------------------------------------------
Ian Kluft RAS Lab
hplabs!hprasor!kluft HP Network Systems Group
kluft at hpda.hp.com Cupertino, CA
------------------------------------------------------------
-----------------------------
From: John Coughlin <jc at sce.uucp>
Subject: Recommendations wanted for workstations and CASE tools
Date: 25 Jun 88 16:20:27 GMT
To: info-unix at SEM.BRL.MIL
Our company will soon be purchasing a number of workstations
for use in software development with CASE tools. We are currently
considering Apollo or Sun machines and I would appreciate any
recommendations.
----------------------------------------------------------------------
Paul Burry UUCP: sce!jc
Dy4 Systems Inc. PHONE: (613)-596-9911
21 Credit Union Way,
Nepean, Ontario
Canada K2H 9G1
----------------------------------------------------------------------
-----------------------------
From: Geoff Rimmer <maujd at warwick.uucp>
Subject: Re: "cd path" strangeness
Date: 26 Jun 88 22:31:54 GMT
Sender: news at warwick.uucp
Keywords: csh cd xenix sysv
To: info-unix at brl-sem.arpa
In article <922 at .UUCP> jbush at ficc.UUCP (james bush) writes:
>In article <337 at vector.UUCP>, chip at vector.UUCP (Chip Rosenthal) writes:
>> Here is a wierd one. In csh, move to some directory which doesn't have
>> a "path" subdirectory. Then type either "cd path" or "chdir path".
>>
>> The expected response would be "path: No such file or directory." Instead,
>> no message is issued, and either you stay where you were or you move to
>> $path[1]...
>
>This is even more wierd. I tried it on our Intel Xenix system, and it worked
>as you said when I did it under my login. However, when I tried to show it
>to my friend under his id, it came up with the "expected" error message! I
>am not sure what the difference is.
Perhaps he uses Bourne shell?
extravagent_prompt % sh
$ cd path
path: bad directory
$
No flames please - term finishes in under a week - so I won't be here
to read them 8-)
Geoff.
>James Bush, Ferranti, Houston Praise the Lord
>Internal address: jbush extension 5230, mail stop A/3204, room A/3602
>External address: ..!uunet!nuchat!sugar!ficc!jbush
-----------------------------------------------------------------
Geoff Rimmer, Computer Science, Warwick University, UK.
maujd at uk.ac.warwick.opal
"I do SMILE humour - people aren't SUPPOSED to laugh."
"Yeah, but they aren't supposed to throw heavy objects
and shout 'Get off you boring bastard, we've heard better
jokes on the speaking clock!'"
- Filthy Rich and Catflap (BBC TV)
(Get your local TV station to buy this excellent comedy series!!)
-----------------------------------------------------------------
-----------------------------
From: Joel Clark <joel at intelisc.uucp>
Subject: Re: RCS and SCCS
Date: 27 Jun 88 17:28:47 GMT
To: info-unix at brl-sem.arpa
In article <661 at pyuxe.UUCP> mayerar at pyuxe.UUCP (80132-A Mayer) writes:
>In article <710 at ubu.warwick.UUCP> maujd at warwick.UUCP (Geoff Rimmer) writes:
>>Which out of RCS and SCCS do people prefer?
>>
>>Geoff.
>
>One good point of RCS is that it stores the most recent version and
>uses deltas to get back to the previous versions. SCCS stores the
>original version and uses deltas to get to the most recent version.
>
> Andrew J. Mayer
> BELLCORE
>
>{ariel,burl,clyde,floyd,gamma,harpo,ihnp4,mhuxl,rutgers}!pyuxe!mayerar
Even though I have written software with similar functionality as SCCS,
I have never understood this argument about storing the most recent
version as opposed to storing the original version. For example given
the following actual SCCS file:
I 1
/*
* module control port settings
*/
D 2
#define NPGM_DONE 0x01
E 2
I 2
#define RRCV 0x02
E 2
#define RLSRCV 0x02
#define NPROGRAM 0x80
E 1
We see the original and the most recent stored in the same manor, line
by line. Any program trying to a extract version still has to look at
every line to decide if that line is in the desired version or not.
Can anyone explain to me how a program could store `the most recent version`
such that each line in the file does not need to be examined to determine
if it is in the most recent version?
Joel Clark
Intel Scientific Computers joel at intelisc.uucp.com
Beaverton, OR {tektronix}!ogcvax!intelisc!joel
(503) 629 7732
-----------------------------
From: "David I. Berg" <dberg at cod.nosc.mil>
Subject: Re: RCS and SCCS
Date: 28 Jun 88 16:14:24 GMT
To: info-unix at brl-sem.arpa
In article <710 at ubu.warwick.UUCP>, maujd at warwick.UUCP (Geoff Rimmer) writes:
> Which out of RCS and SCCS do people prefer? ..........
> ..... What are the good and bad points of each system?
>
I have used both systems, depending on which was available on the particular
computer I was using. I find RCS particularly easier to use than SCCS.
In fact, in one case, I converted all my SCCS files to RCS using the
sccstorcs utility. Another feature of RCS is that it stores the current
version of your file and the changes backward to the original, whereas
SCCS stores the original version of your file and the changes forward
to the current. Therefore, it will take SCCS a trifle longer to produce
the current version than RCS.
-----------------------------
From: Eduardo Krell <ekrell at hector.uucp>
Subject: Re: RCS and SCCS
Date: 28 Jun 88 19:22:01 GMT
Sender: netnews at ulysses.homer.nj.att.com
To: info-unix at SEM.BRL.MIL
In article <290 at intelisc.UUCP> joel at intelisc.UUCP (Joel Clark) writes:
>Can anyone explain to me how a program could store `the most recent version`
>such that each line in the file does not need to be examined to determine
>if it is in the most recent version?
You store the most recent version at the beginning of the file in clear
text followed by the reverse delta to get the previous version
(followed by the reverse delta to get the version before that, etc.).
Time to get the latest version is thus proportional only to the size of
that version. Time to get version N is proportional to the size of
the last version plus the size of all deltas necessary to get from there
down to version N.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell at ulysses.att.com
-----------------------------
From: Richard Harter <g-rh at cca.cca.com>
Subject: Re: RCS and SCCS
Date: 28 Jun 88 20:08:42 GMT
To: info-unix at SEM.BRL.MIL
In article <290 at intelisc.UUCP> joel at intelisc.UUCP (Joel Clark) writes:
>Can anyone explain to me how a program could store `the most recent version`
>such that each line in the file does not need to be examined to determine
>if it is in the most recent version?
There are two different ways that I know of to do this. One is the way RCS
does it. When the file is updated the delta is calculated in terms of carrying
the latest version to the previous version. The delta is appended to the stored
deltas, and the previous version is replaced by the updated version. I can't
give you the details on the other way (it is proprietary to ADC) but the
essence of the matter is the information about the lines do not have to be
stored with the lines.
--
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.
-----------------------------
From: Joe Bob Willie <haugj at pigs.uucp>
Subject: Re: RCS and SCCS
Date: 28 Jun 88 21:46:14 GMT
To: info-unix at brl-sem.arpa
In article <29975 at cca.CCA.COM>, g-rh at cca.CCA.COM (Richard Harter) writes:
> It is true, however, that there is, in principle, a signifigant performance
> advantage for the RCS scheme versus the SCCS scheme. SCCS must process
> all lines including those not currently active; RCS need only process those
> that are currently active. Furthermore RCS does not need to do any processing
> on the line other than copying it out; SCCS has to check the control data
> for the line. On the other hand, RCS pays a penalty if the version being
> extracted is not the latest.
> --
> Richard Harter, SMDS Inc.
[ In the Oil Fields of HELL,
Where the drought grows long and HOT ]
OK - I'll bite, and I'm sure others will also. What exactly does an
RCS file look like. I'm a die-hard SCCS junkie. How about a few
specific examples for those of us without RCS or RCS documentation.
- John.
--
The Beach Bum Big "D" Home for Wayward Hackers
UUCP: ...!killer!rpp386!jfh jfh at rpp386.uucp :SMAILERS
"You are in a twisty little maze of UUCP connections, all alike" -- fortune
-----------------------------
From: Clark Morgan <clarkm at tekig4.tek.com>
Subject: Re: HOW DO I MAKE VI'S AUTOINDENT NOT USE TABS?
Date: 28 Jun 88 07:53:13 GMT
To: info-unix at SEM.BRL.MIL
?In article <1219 at bakerst.UUCP> kathy at bakerst.UUCP (Kathy Vincent) writes:
>In article <2965 at tekig4.TEK.COM> clarkm at tekig4.UUCP I whine:
>
> ....about Vi putting tabs in my files....
>
?I'm coming in late to this discussion, so if I missed something,
?well, sorry.
?
?But there *is* an option that says not to auto-tab.
?
?I use vi all the time - using SVR2 and SVR3 on 3B20s, and using
?3.5 UNIX on my on my UNIX PC. I never get any tabs I don't explicitly
?ask for.
?
?I did a
?
? :se all
?
?to check the settings I have when I'm working, and included in the
?list is one
?
? noautoindent
?
?That must be the default on all the systems I work on because I don't
?ever set up anything.
....
?
?Kathy Vincent ------> {ihnp4|att|codas|pacbell}!bakerst!kathy
? ------> { favourite AT&T gateway }!wruxh!unix
====================================================================
Um Kathy, I want autoindent + NO TABS (for C programs and the like).
====================================================================
--
Clark Morgan, Tektronix Lab Instruments Engineering (503) 627-3545
clarkm at tekig4.LEN.TEK.COM | {...,decvax,uw-beaver}!tektronix!tekig4!clarkm
US Mail: Tektronix, P.O. Box 500, DS 39-087, Beaverton, OR 97077
-----------------------------
From: Felix Lee <flee at gondor.cs.psu.edu>
Subject: Shouting the return code. (Re: Meaning of "rc" in cron/log)
Date: 28 Jun 88 11:08:37 GMT
Sender: news at psuvax1.cs.psu.edu
To: info-unix at SEM.BRL.MIL
Does ksh let you put the return code in the prompt? Something like
PS1='($?) '? Showing only non-zero return codes would be better.
Return codes are interesting. Really. IBM's VM/CMS will tell you about
non-zero return codes. (The prompt is either 'R;' or 'R(nnn);')
Unix hides return codes well. Ever try unconfusing someone about why
"true" is "exit 0", but "false" is "exit 1"?
Maybe if the shell shouted the return code, more programs would return
interesting codes. (lament) Where are the return codes for fsck
documented? Why does "strings" return -40? Why does "od" return 10?
--
Felix Lee flee at gondor.cs.psu.edu *!psuvax1!gondor!flee
-----------------------------
From: "Wolf N. Paul" <wnp at dcs.uucp>
Subject: Re: how can I "." in csh?
Date: 28 Jun 88 12:32:45 GMT
To: info-unix at brl-sem.arpa
In article <3513 at ncrcae.Columbia.NCR.COM> rogerc at ncrcae.Columbia.NCR.COM (Roger
Collins) writes:
>In csh, is there an easy way to duplicate the function of Bourne's "."
>command? I want to input commands from a file and have them
>change the current layer's environment.
The csh command you want is called "source". Thus, "source .login" is
roughly equivalent to the Bourne/Korn shell command ". .profile".
--
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP: killer!dcs!wnp ESL: 62832882
DOMAIN: wnp at dcs.UUCP TLX: 910-380-0585 EES PLANO UD
-----------------------------
From: Bob Mende Pie <mende at porthos.rutgers.edu>
Subject: Re: how can I "." in csh?
Date: 28 Jun 88 14:03:12 GMT
To: info-unix at SEM.BRL.MIL
In article <3513 at ncrcae.Columbia.NCR.COM> rogerc at ncrcae.Columbia.NCR.COM (Roger
Collins) writes:
> In csh, is there an easy way to duplicate the function of Bourne's "."
> command? I want to input commands from a file and have them
> change the current layer's environment.
The command you want is source.
/Bob...
--
{...}!rutgers!mende mende at aramis.rutgers.edu mende at zodiac.bitnet
YOU can't talk, your SHIRT is BROKEN.
-----------------------------
From: Lloyd Zusman <ljz at fxgrp.uucp>
Subject: Re: how can I "." in csh?
Date: 28 Jun 88 20:05:42 GMT
To: info-unix at brl-sem.arpa
In article <129 at dcs.UUCP> wnp at dcs.UUCP (Wolf N. Paul) writes:
In article <3513 at ncrcae.Columbia.NCR.COM> rogerc at ncrcae.Columbia.NCR.COM
(Roger Collins) writes:
>In csh, is there an easy way to duplicate the function of Bourne's "."
>command? ...
The csh command you want is called "source". Thus, "source .login" is
roughly equivalent to the Bourne/Korn shell command ". .profile".
... and you can even get a bona fide "." command in csh by means of
an alias:
alias . source
... would do the trick. You'd probably want to put this in your .cshrc
file.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com at ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz at ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: "Lawrence V. Cipriani" <lvc at tut.cis.ohio-state.edu>
Subject: Re: Shouting the return code. (Re: Meaning of "rc" in cron/log)
Date: 28 Jun 88 14:46:42 GMT
To: info-unix at SEM.BRL.MIL
In article <3671 at psuvax1.cs.psu.edu>, flee at gondor.cs.psu.edu (Felix Lee) writes:
> Does ksh let you put the return code in the prompt? Something like
> PS1='($?) '?
Yes, this PS1 displays the exit value of the "previous command". $? will
change value on an interrupt however.
> Showing only non-zero return codes would be better.
Why? Knowing a command completed successfully might be useful if
stdout/stderr for the command were redirected.
> Return codes are interesting. Really. IBM's VM/CMS will tell you about
> non-zero return codes. (The prompt is either 'R;' or 'R(nnn);')
Return codes are boring. Really.
> Unix hides return codes well.
If you need them you can get them, if you don't want to see them you
don't have to. I bet you don't have this flexibility in IBM's VM/CMS.
My feeling is the shorter my PS1 prompt the better. There was a time
when my PS1 included my login id, the machine name I was logged in on,
the time of day (you can do this in ksh), and even some graphics
sequences. After a few weeks I changed it all back to just the machine
name (since I will simultaneously be logged in several systems).
>Ever try unconfusing someone about why
> "true" is "exit 0", but "false" is "exit 1"?
Yeah, and read the man page for true/false to them, it always gets
funny looks, and usually some laughs after you explain it to them.
...
> Felix Lee flee at gondor.cs.psu.edu *!psuvax1!gondor!flee
--
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc at tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
-----------------------------
From: "William E. Davidsen Jr" <davidsen at steinmetz.ge.com>
Subject: Re: Is a NEED for more COMMERCIAL usenet feed providers?
Date: 28 Jun 88 16:44:39 GMT
To: info-unix at SEM.BRL.MIL
In article <317 at ditka.UUCP> kls at ditka.UUCP (Karl Swartz) writes:
| Greg, I know this isn't exactly what you had in mind, but what about
| a west coast uunet? While helping a (non-local) friend look into
| news feed options, I realized that uunet costs a *lot* more for west
| coast folks than those who are closer. This is based on a TrailBlazer
For low budget sites, uunet can be reached by PC Pursuit and Dial
America service. This keeps the cost way down. If you need to send stuff
during the day, of course, you will still be faced with a stiff bill. If
you are looking for a local feed, rather than the gateway features uunet
provides, you should be able to find one almost anywhere. I think portal
will feed anyone on the west coast for a price, but I have no idea what
that price is.
--
bill davidsen (wedu at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: Keith Ericson <keithe at tekgvs.tek.com>
Subject: Re: AT&T vs. CSS (PC/Tools)
Date: 28 Jun 88 18:46:18 GMT
Keywords: AT&T, lawsuit, CSS, PC/Tools, PC/VI
To: info-unix at SEM.BRL.MIL
In article <142 at wash08.UUCP> txr98 at wash08.UUCP (Timothy Reed) writes:
>A friend at ATT told me last year that ATT owned more than afew copies
>of the MKS toolkit on DOS PCs at most of their sites in Jersey. If MKS
>didn't license unix from ATT, would that be considered tacit approval?
>
Never assume that any one part of a large organization even knows,
much less approves, of what another department, section, group or
whatever is doing.
keith
-----------------------------
From: The Silent Killer <patkar at cb.ecn.purdue.edu>
Subject: Tabs in VI
Date: 28 Jun 88 19:01:17 GMT
To: info-unix at brl-sem.arpa
> ====================================================================
> Um Kathy, I want autoindent + NO TABS (for C programs and the like).
> ====================================================================
The way I do it is by using the unix utility 'expand' from within
'VI'. I know this does not prevent insertion of tabs, but it at least
removes them once you have used the command
!<movement command>expand
The <movement command> may be (, {, 1G etc. In writing LISP functions,
for example, I find the command '!%expand' very useful.
Anant Patkar.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o
__________________ ____________________________
/ ) | | ___| | | | _| __|_ / | patkar at ecn.purdue.edu
---| o--| ( | `___| | ' '__| ) o/ | patkar at purche.BITNET
\_) | | \ | | | `-- | \
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------
From: Lyndon Nerenberg <lyndon at ncc.nexus.ca>
Subject: SLIP protocol specification
Date: 28 Jun 88 20:11:23 GMT
To: info-unix at SEM.BRL.MIL
Lately there have been a number of requests for a description of
the SLIP encapsulation scheme for sending IP packets over serial
links. SRI has (finally :-) issued an RFC describing how this is
currently implemented. It's only six pages long, so I've attached
a copy. Apologies if you've already seen this.
(cut the .signature at the end)
--lyndon VE6BBM
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Network Working Group J. Romkey
Request for Comments: 1055 June l988
A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP
INTRODUCTION
The TCP/IP protocol family runs over a variety of network media:
IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
satellite links, and serial lines. There are standard encapsulations
for IP packets defined for many of these networks, but there is no
standard for serial lines. SLIP, Serial Line IP, is a currently a de
facto standard, commonly used for point-to-point serial connections
running TCP/IP. It is not an Internet standard. Distribution of
this memo is unlimited.
HISTORY
SLIP has its origins in the 3COM UNET TCP/IP implementation from the
early 1980's. It is merely a packet framing protocol: SLIP defines a
sequence of characters that frame IP packets on a serial line, and
nothing more. It provides no addressing, packet type identification,
error detection/correction or compression mechanisms. Because the
protocol does so little, though, it is usually very easy to
implement.
Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and
Sun Microsystems workstations and released it to the world. It
quickly caught on as an easy reliable way to connect TCP/IP hosts and
routers with serial lines.
SLIP is commonly used on dedicated serial links and sometimes for
dialup purposes, and is usually used with line speeds between 1200bps
and 19.2Kbps. It is useful for allowing mixes of hosts and routers
to communicate with one another (host-host, host-router and router-
router are all common SLIP network configurations).
AVAILABILITY
SLIP is available for most Berkeley UNIX-based systems. It is
included in the standard 4.3BSD release from Berkeley. SLIP is
available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX
systems. Some terminal concentrators and IBM PC implementations also
support it.
SLIP for Berkeley UNIX is available via anonymous FTP from
uunet.uu.net in pub/sl.shar.Z. Be sure to transfer the file in
binary mode and then run it through the UNIX uncompress program. Take
Romkey [Page 1]
RFC 1055 Serial Line IP June 1988
the resulting file and use it as a shell script for the UNIX /bin/sh
(for instance, /bin/sh sl.shar).
PROTOCOL
The SLIP protocol defines two special characters: END and ESC. END is
octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be
confused with the ASCII ESCape character; for the purposes of this
discussion, ESC will indicate the SLIP ESC character. To send a
packet, a SLIP host simply starts sending the data in the packet. If
a data byte is the same code as END character, a two byte sequence of
ESC and octal 334 (decimal 220) is sent instead. If it the same as
an ESC character, an two byte sequence of ESC and octal 335 (decimal
221) is sent instead. When the last byte in the packet has been
sent, an END character is then transmitted.
Phil Karn suggests a simple change to the algorithm, which is to
begin as well as end packets with an END character. This will flush
any erroneous bytes which have been caused by line noise. In the
normal case, the receiver will simply see two back-to-back END
characters, which will generate a bad IP packet. If the SLIP
implementation does not throw away the zero-length IP packet, the IP
implementation certainly will. If there was line noise, the data
received due to it will be discarded without affecting the following
packet.
Because there is no 'standard' SLIP specification, there is no real
defined maximum packet size for SLIP. It is probably best to accept
the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006
bytes including the IP and transport protocol headers (not including
the framing characters). Therefore any new SLIP implementations
should be prepared to accept 1006 byte datagrams and should not send
more than 1006 bytes in a datagram.
DEFICIENCIES
There are several features that many users would like SLIP to provide
which it doesn't. In all fairness, SLIP is just a very simple
protocol designed quite a long time ago when these problems were not
really important issues. The following are commonly perceived
shortcomings in the existing SLIP protocol:
- addressing:
both computers in a SLIP link need to know each other's IP
addresses for routing purposes. Also, when using SLIP for
hosts to dial-up a router, the addressing scheme may be quite
dynamic and the router may need to inform the dialing host of
Romkey [Page 2]
RFC 1055 Serial Line IP June 1988
the host's IP address. SLIP currently provides no mechanism
for hosts to communicate addressing information over a SLIP
connection.
- type identification:
SLIP has no type field. Thus, only one protocol can be run
over a SLIP connection, so in a configuration of two DEC
computers running both TCP/IP and DECnet, there is no hope of
having TCP/IP and DECnet share one serial line between them
while using SLIP. While SLIP is "Serial Line IP", if a serial
line connects two multi-protocol computers, those computers
should be able to use more than one protocol over the line.
- error detection/correction:
noisy phone lines will corrupt packets in transit. Because the
line speed is probably quite low (likely 2400 baud),
retransmitting a packet is very expensive. Error detection is
not absolutely necessary at the SLIP level because any IP
application should detect damaged packets (IP header and UDP
and TCP checksums should suffice), although some common
applications like NFS usually ignore the checksum and depend on
the network media to detect damaged packets. Because it takes
so long to retransmit a packet which was corrupted by line
noise, it would be efficient if SLIP could provide some sort of
simple error correction mechanism of its own.
- compression:
because dial-in lines are so slow (usually 2400bps), packet
compression would cause large improvements in packet
throughput. Usually, streams of packets in a single TCP
connection have few changed fields in the IP and TCP headers,
so a simple compression algorithms might just send the changed
parts of the headers instead of the complete headers.
Some work is being done by various groups to design and implement a
successor to SLIP which will address some or all of these problems.
Romkey [Page 3]
RFC 1055 Serial Line IP June 1988
SLIP DRIVERS
The following C language functions send and receive SLIP packets.
They depend on two functions, send_char() and recv_char(), which send
and receive a single character over the serial line.
/* SLIP special character codes
*/
#define END 0300 /* indicates end of packet */
#define ESC 0333 /* indicates byte stuffing */
#define ESC_END 0334 /* ESC ESC_END means END data byte */
#define ESC_ESC 0335 /* ESC ESC_ESC means ESC data byte */
/* SEND_PACKET: sends a packet of length "len", starting at
* location "p".
*/
void send_packet(p, len)
char *p;
int len; {
/* send an initial END character to flush out any data that may
* have accumulated in the receiver due to line noise
*/
send_char(END);
/* for each byte in the packet, send the appropriate character
* sequence
*/
while(len--) {
switch(*p) {
/* if it's the same code as an END character, we send a
* special two character code so as not to make the
* receiver think we sent an END
*/
case END:
send_char(ESC);
send_char(ESC_END);
break;
/* if it's the same code as an ESC character,
* we send a special two character code so as not
* to make the receiver think we sent an ESC
*/
case ESC:
send_char(ESC);
send_char(ESC_ESC);
break;
Romkey [Page 4]
RFC 1055 Serial Line IP June 1988
/* otherwise, we just send the character
*/
default:
send_char(*p);
}
p++;
}
/* tell the receiver that we're done sending the packet
*/
send_char(END);
}
/* RECV_PACKET: receives a packet into the buffer located at "p".
* If more than len bytes are received, the packet will
* be truncated.
* Returns the number of bytes stored in the buffer.
*/
int recv_packet(p, len)
char *p;
int len; {
char c;
int received = 0;
/* sit in a loop reading bytes until we put together
* a whole packet.
* Make sure not to copy them into the packet if we
* run out of room.
*/
while(1) {
/* get a character to process
*/
c = recv_char();
/* handle bytestuffing if necessary
*/
switch(c) {
/* if it's an END character then we're done with
* the packet
*/
case END:
/* a minor optimization: if there is no
* data in the packet, ignore it. This is
* meant to avoid bothering IP with all
* the empty packets generated by the
* duplicate END characters which are in
Romkey [Page 5]
RFC 1055 Serial Line IP June 1988
* turn sent to try to detect line noise.
*/
if(received)
return received;
else
break;
/* if it's the same code as an ESC character, wait
* and get another character and then figure out
* what to store in the packet based on that.
*/
case ESC:
c = recv_char();
/* if "c" is not one of these two, then we
* have a protocol violation. The best bet
* seems to be to leave the byte alone and
* just stuff it into the packet
*/
switch(c) {
case ESC_END:
c = END;
break;
case ESC_ESC:
c = ESC;
break;
}
/* here we fall into the default handler and let
* it store the character for us
*/
default:
if(received < len)
p[received++] = c;
}
}
}
Romkey [Page 6]
--
{alberta,pyramid,uunet}!ncc!lyndon lyndon at Nexus.CA
-----------------------------
From: ok at quintus
Subject: Termcap/Terminfo question
Date: 28 Jun 88 20:48:27 GMT
Sender: news at quintus.uucp
To: info-unix at brl-sem.arpa
When should a program use the 'is' (initialisation string) or 'if'
(initialisation file) capabilities? I have a program which sends this
string when it starts, but a number of VT100 emulators adapt to window
size by adding appropriate co#COLS and li#ROWS information, but leave
is: setting the scrolling region to 24 lines, which seems unhelpful.
There seem to be three sets of strings a program might send at start
and finish:
is/rs initialisation string / reset string
[is1..is3/rs1..rs3 in terminfo; also if/rf]
vs/ve "visual" start / "visual" end
ti/te said to be meant for things that use cm (cursor motion)
Exactly when should these things be used?
Is there a book which explains in clear and simple language what each of
the capabilities means, how to decide what to set it to, and when to use it?
[I have the 5R3 manuals. I need an idiot's guide.]
-----------------------------
From: "M. D. Parker" <mparker at chip.uucp>
Subject: UUCP Over TCP/IP
Date: 28 Jun 88 20:52:12 GMT
Keywords: uucp, uucpd, bsd4.3
To: info-unix at brl-sem.arpa
In bits of the BSD documentation, there is a mention of the TCP/IP UUCP server
deamon (i.e. /etc/uucpd). My question is if you are the sending party, how
do you tell the system to use the UUCP protocol? I find nothing in this
in connection with the L.sys file, in fact, I have really found nothing at
all.
Can anybody enlighten me on /etc/uucpd and its operation, invokation, etc.?
Thanks....
-----------------------------
From: Doug Landauer <landauer at morocco.sun.com>
Subject: Re: RCS and SCCS (and CMS)
Date: 28 Jun 88 21:25:47 GMT
Sender: news at sun.uucp
Keywords: CMS RCS SCCS
To: info-unix at brl-sem.arpa
In article <1134 at cod.NOSC.MIL>, dberg at cod.NOSC.MIL (David I. Berg) wrote:
> Another feature of RCS is that it stores the current
> version of your file and the changes backward to the original, whereas
> SCCS stores the original version of your file and the changes forward
> to the current.
This is a common misconception (oversimplification) -- it implies that
it could take significantly longer using SCCS to get the current
version of the file than for it to get the original version. In fact,
SCCS does not store separate deltas; it stores all of the deltas
together, in the appropriate places within "the original file", in the
file in such a way that it takes about the same amount of time to get
any version.
There are several barely relevant performance implications of the
differences between this scheme and what RCS does:
+ for RCS: For retrieving the latest version (RCS is betting that
this is the most common case), RCS is likely to be faster;
~ : For retrieving any other versions, RCS slows down relative
to its own performance on the latest version (and at some point
depending on how many deltas as well as how many lines changed
per delta, it may be slower than SCCS);
+ for SCCS: Doing RCS check-ins (storing new versions) should be
distinctly slower than doing SCCS deltas;
> I find RCS particularly easier to use than SCCS.
I personally agree with this statement (disclaimer: Sun doesn't
officially agree). The BSD "sccs" front-end command helps some.
Finally, the performance differences mentioned above probably add up
(over the course of my entire SCCS career) to less time than I spent
composing this message (as David I. Berg put it, "it will take SCCS a
trifle longer"), so the ease-of-use factor should become the overriding
factor if you're starting a new project in a new company or on your
own. In practice, the "what-they-use-here" factor is the real
overriding factor.
This is one of the few areas where VMS (gasp!) really does do better
than Unix (IMHO) -- DEC's CMS (though it has brain damage in some ways)
really does have some features that would make it, on the whole, better
than either SCCS or RCS, if you could use it on Unix instead of VMS.
--
Doug Landauer Sun Microsystems, Inc.
ARPA Internet: landauer at sun.com Software Products Division
UUCP: ...!sun!landauer
--
Acronym glossary: (Some of these are trademarks -- you know who you are.)
BSD -- Berkeley Software Distribution
CMS -- Code Management System (I think)
DEC -- Digital Equipment Corporation
IMHO -- In My Humble Opinion
RCS -- Revision Control System
SCCS -- Source Code Control System
UUCP -- Unix-to-Unix CoPy
VMS -- Virtual Memory System (an operating system for some DEC computers)
--
-----------------------------
From: Adam Moskowitz <adamm at necis.uucp>
Subject: Getting vi to automagically use macros
Date: 28 Jun 88 23:01:19 GMT
Keywords: vi, macros
To: info-unix at SEM.BRL.MIL
This has probably been asked before, but since limited disk space prevents me
from saving everything I might ever need . . .
Is there a way to set up some vi macros via my .exrc file or the EXINIT
environment variable? I know that I can fake it my mapping the two-char
sequence "@x" to the string I want, but is there a way to automatically
have a "real" macro set up every time I start-up vi?
E-MAIL me your replies and I'll summarize to the net if I get anything.
Thanx in advance.
--
Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm
"The morning blues, they make me feel so bad;
it's the worst damn feeling I ever had."
-----------------------------
End of INFO-UNIX Digest
***********************
More information about the Comp.unix.questions
mailing list