From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Haertel Message-Id: <200101311746.f0VHkZM02465@ducky.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P2000 In-Reply-To: <20010131093143.BA424199FA@mail.cse.psu.edu> Date: Wed, 31 Jan 2001 09:46:35 -0800 Topicbox-Message-UUID: 55bcfe0e-eac9-11e9-9e20-41e7f4b1d025 >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.