Re: [9fans] 9P2000

[Mike Haertel <mike@ducky.net>]

>	* 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.