Re: [9fans] venti workalike in Python

["Russ Cox" <rsc@swtch.com>]

> I'm attempting to decipher the venti and vac code and write a workalike in
> Python.  (packet.c had me bogged down for a while...)  At this point I don't

The discussion of the Vac file system format in /sys/doc/fossil.ps
may be helpful.

> care that much about compatibility, and can't really test it as I don't have
> a running instance of Plan 9.  But as has been noted here before, the venti
> procol is relatively trivial--hello, ping, read, write, goodbye, error,
> although the two auth messages appear to be unused for the moment?--so
> making it compatible at some point shouldn't be too much of a problem.
> Having said that, is there any documentation on the venti protocol apart
> from the source?

Not really, but here's a summary.

Venti uses a simple RPC protocol with only a few messages:

	size[2] RError   tag[1] error[s]

	size[2] QPing    tag[1]
	size[2] RPing    tag[1]

	size[2] QHello   tag[1] version[s] uid[s] strength[1]
	                              ncrypto[1] crypto[ncrypto]
	                              ncodec[1] codec[ncodec]
	size[2] RHello   tag[1] sid[s] crypto[1] codec[1]

	size[2] QGoodbye tag[1]

	size[2] QRead    tag[1] score[20] type[1] 0[1] count[2]
	size[2] RRead    tag[1] data[]

	size[2] QWrite   tag[1] type[1] 0[3] data[]
	size[2] RWrite   score[20]

	size[2] QSync    tag[1]
	size[2] RSync    tag[1]

In the notation, field[s] indicates a string: a two-byte length followed
by that many bytes.

The actual message types are one-byte values:

enum
{
	VtRError = 1,

	VtQPing,
	VtRPing,
	VtQHello,
	VtRHello,
	VtQGoodbye,
	VtRGoodbye,	/* not used */
	VtQAuth0,	/* not used */
	VtRAuth0,	/* not used */
	VtQAuth1,	/* not used */
	VtRAuth1,	/* not used */
	VtQRead,
	VtRRead,
	VtQWrite,
	VtRWrite,
	VtQSync,
	VtRSync,

	VtMaxOp
};

Transactions and tags are like in 9P, except that tags are one byte
and the request messages have names beginning with Q instead of T.
The strength, crypto, and codec stuff was never fleshed out and
is essentially unused.

> I'm not planning on re-implementing venti's arena code but thought that it
> would be quick and easy for testing purposes to implement the back-end
> storage using something like dbm or, mea culpa, a relational database.  (I
> added binary type support to the Python extension for SQLite with this in
> mind.)  Thoughts?

We use Berkeley DB at MIT for another project to store 8kB blocks indexed
by SHA1 hash.  It's adequate.

Russ