From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Haertel Message-Id: <200101310856.f0V8unG01542@ducky.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] 9P2000 In-Reply-To: <20010131021645.EBC6E199F8@mail.cse.psu.edu> Date: Wed, 31 Jan 2001 00:56:49 -0800 Topicbox-Message-UUID: 5570e0be-eac9-11e9-9e20-41e7f4b1d025 > * eliminate multiple Tsessions from the protocol; require > that each connection begin with exactly one Tversion, > exactly one Tsession, and disallow any further occurrences > of Tsession and Tversion in the conversation. then the > funny "aborts all transactions" semantics of Tsession can > also be eliminated. > >The requirement for Tsession to reset a connection is there so 9P can >be used on point-to-point wired networks such as the old BIT32 or >other back-to-back bus devices. If every connection to the server >begins as an IP call, I admit Tsession is less useful, but there are >setups for which Tsession provides the necessary reset capability. ~0 >is a reserved tag so one may always issue a `reset' this way. Ok, that's what I thought. Did you take the time to read my argument (in the longer discussion) that this is a bogus consideration? Here's why: imagine you have a hard-wired connection. Suppose moreover that your client crashes *in the middle* of sending a message. Then the client reboots and starts by sending a new Tversion message, but the server still thinks it is in the middle of whatever message the client was previously sending. So the server never resynchronizes with the client, and the client ends up thinking the server is being stubborn and never responding, or else sending back garbage. In order to avoid this scenario you need some kind of markers that the server can look for once it realizes it has become desynchronized. One simple approach might be simply to prefix every 9P message with a particular magic byte that the server can look for. As long as that magic byte is seen whenever the server is about to begin reading a new message, it knows it is (probably) synchronized. If it becomes desynchronized it can hunt for the magic byte in an attempt to become resychronized. This is the sort of service an underlying transport protocol provides robustly. You could include this functionality in 9P, but why? The Tsession stuff has to be one of the most non-robust ways of doing this that I have ever seen. If you've had no problem with unencapsulated 9P on hard-wired links so far, it's only because you've been lucky. Better by far to assume a real underlying transport layer. It could be as simple as a trivial wrapper that puts delimiter bytes on messages before sending them on a your hardwired connection. Even something as simple as that will do a better job of crash recovery than 9P by itself.