Re: [9fans] 9P2000

[Mike Haertel <mike@ducky.net>]

>Aren't there two issues here?  One is resynchronizing
>the message stream, so that both sides agree on the 
>message boundaries.  The other is resynchronizing 
>the 9P conversation state, so that both sides agree
>on which tags and fids are in use and what they mean.

Yes.

>Something (an underlying transport protocol, say) needs
>to provide the first capability, but without the second
>you're still hosed.  In an IP environment, you can drop
>and redial the connection,

Yes, in an IP environment, the connection gets closed, and the
other end of the conversation detects that *independently of
the 9P byte stream*, when attempting to read or write the connection
returns some kind of "EOF" indication.

>but if you've got a hard-wired
>link, you need an explicit restart within the protocol,
>hence Tsession, no?

Nope.  Because we've already established that in a a hard-wired
environment 9P cannot reliably be the lowest level protocol.

Therefore, we know we already NEED a lower level below 9P,
just to delimit message boundaries.  Why not just make that
lower level also know how to "return EOF"?

Then, to the higher 9P level, the hard wired link would look
*just like* and IP connection.  So the higher level would have
only one execution environment to cope with, instead of two
subtly different ones.

Let
	A = total_complexity_of(9P + Tsession abort and ~0 tags)
	B = total_complexity_of(encapsulation layer that doesn't "return EOF")
	C = total_complexity_of(9P with those features removed)
	D = total_complexity_of(encapsulation layer that does return EOF)

My argument is simply that

	A + B > C + D

But, if you guys aren't comfortable with this, I guess it's
not worth arguing about further.