Re: [9fans] server push in 9P protocol

[andrey mirtchovski <mirtchovski@gmail.com>]

you don't need 'push', simply always send a 'Tread' from the client
when an Rread is received. the Tread will "hang" until there's data
for it. this will save you from having two messages traverse right
when the data is supposed to be on the line as you can send the next
Tread after processing (off-peak).


On Wed, Oct 15, 2014 at 9:56 AM,  <smiley@icebubble.org> wrote:
> Hello,
>
> I'm wondering if there is any way to do server push using the 9P
> protocol.  I'm trying to imagine use of 9P for applications such as data
> acquisition.  One example might be caputing MIDI messages from digital
> musical instruments.
>
> As I understand the protocol, if an instrument served MIDI over 9P,
> every MIDI message would have to be explicitly requested with a Tread.
> And the instrument would have to wait for a Tread in order to send data.
> If the instrument (server) sent more than one Rread with the same tag,
> that would be a violation of the protocol.
>
> It might be possible to reverse roles: for the instrument to act as a 9P
> client and treat the MIDI host as a 9P server.  In that case, each MIDI
> message could take the form of a Twrite to the MIDI host.  But that
> would generate a series of Rwrites back from the host to the instrument,
> which would be unnecessary and have to be ignored.
>
> Another example might be isochronous data streams, such as video
> captured at a fixed framerate from a video capture device.  Having to
> send the same Tread or Rread 30x/second seems silly.
>
> So, is there any way use 9P in a server-push mode, where the server
> spits out a stream of data to be captured?
>
> Thanks!
>