Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: pty bugs & features
Message-ID: <1839@necisa.ho.necisa.oz>
Date: 27 Aug 90 01:37:19 GMT
References: <5992@muffin.cme.nist.gov> <3948@auspex.auspex.com> <6038@muffin.cme.nist.gov> <3954@auspex.auspex.com>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 55

In article <3954@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>
>It could be.  Unfortunately, just about *any* close behavior is going to
>screw *somebody*.
>

This is the _classic_ `virtual circuit problem'.  The problem of
deciding what is circuit shutdown [error] and what is end of data,
and which is appropriate.  You've got to make _all_ the right choices,
and some of them are _hard_.

The way I like to think about it is the way pipes work.  A close
on a pipe indicates EOF to the reader.  But, a write on a pipe
with no one to read it is an error (SIGPIPE/EPIPE).  But, to
generalise this correctly you need to be able to say `kill this
circuit for me because an error's occurred', so that one
end can say to the other that somethings up.

I say that each protocol layer should be self contained and _clean_.

Now, the ISO people are not going to like this, but with virtual
circuits you require two ways to shutdown a circuit at the protocol
level itself, and not make it the responsibility of the layer above.

I remember all too well the existential horror when I realised (while
writing this X.25 `spool across the wire' print server/client) that
when I said close() it shut the circuit down -- _right now_!!  No
waiting for the data to arrive at the other end -- nothing.  I had
to write this _revolting_ gore, using the Q bit to say:

    X.25 software ABC		    X.25 software DEF

    Client: write(You got that?|Q_BIT) 
				    Server: read() You got that?|Q_BIT
    				    Server: write(I got it|Q_BIT)
				    Server: hangup circuit after `I got it'
					    is delivered
    Client: read() I got it|Q_BIT
    Client: close()		    Server:	close()
    Client: exit()		    Server:	Loop

I didn't want to write any file transfer protocol -- why should I?  After
all, I was using a reliable, sequenced, unduplicated, connection based
virtual circuit.  I just wanted close() to block correctly and for a
subsequent server read() to return 0.  But, X.25 software ABC had an
`interesting' idea about virtual circuits.

So I got to thinking that this was just _wrong_ and that Dennis* did it right.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''

* pure, vanilla, no foul gore, straight streaming V8 stream code