> sure.  you could imagine adding a stream message to
> start some number of reads, but maybe it's enough to
> define that streaming style servers allow the client to
> queue multiple read messages and respond in order.
>
> you can already do that for file transfers by using the
> offset field appropriately.

i tried that, and it didn't seem to speed things up much.  regardless
of the number of concurrent reads, it was still much slower than
streaming TCP.

i couldn't say why though - i just measured it across a slow
trans-atlantic connection.

if you want to experiment, i've attached a version of the Inferno
cp(1) called "streamcp" that uses this technique to try to speed up
file transfer; it allows you to specify the number of concurrent reads
and writes.

perhaps someone that knows something about TCP might be able to say
why this technique can't use more of the available bandwidth?  it'd be
great if it could...