[9fans] server push in 9P protocol

[9fans] server push in 9P protocol

[smiley]

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!

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

[andrey mirtchovski]

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!
>

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

search 9fans archives for 9P streaming. i think nemo and lsub crew had
experimented with some variation i believe.  i'm not sure if it is brought
into Clive, their new effort.


On Wed, Oct 15, 2014 at 8: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!
>
>

[-- Attachment #2: Type: text/html, Size: 1924 bytes --]

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

[Bakul Shah]

On Wed, 15 Oct 2014 15:56:14 -0000 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?

A server can return responses in any order since each request
has a client defined unique tag associated with it. Don't see
why the same connection can't be used both sides to act as a
server for the other....  Though this assumption may be
implicit in code.

John Floren extended 9p for streaming. There was at least one
email thread about it on 9fans.

But why not set up a separate tcp stream? Why do you have to
use 9p?

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

[Fran. j. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

the ideas are in Clive, but the code
won't run for 9p or plan 9. 

but I think I copied somewhere (sources)? ix which was ok for a plan9 world, but experimental. 

> El 15/10/2014, a las 18:55, Skip Tavakkolian <skip.tavakkolian@gmail.com> escribió:
> 
> search 9fans archives for 9P streaming. i think nemo and lsub crew had experimented with some variation i believe.  i'm not sure if it is brought into Clive, their new effort.
> 
> 
>> On Wed, Oct 15, 2014 at 8: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!
> 

[-- Attachment #2: Type: text/html, Size: 2479 bytes --]

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

[David du Colombier]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

> i think nemo and lsub crew had experimented with some variation i believe.

It was called 9pix.

http://9fans.net/archive/2013/06/148

--
David du Colombier

[-- Attachment #2: Type: text/html, Size: 287 bytes --]

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

[erik quanstrom]

On Wed Oct 15 12:56:41 EDT 2014, skip.tavakkolian@gmail.com wrote:

> search 9fans archives for 9P streaming. i think nemo and lsub crew had
> experimented with some variation i believe.  i'm not sure if it is brought
> into Clive, their new effort.

john f also did something related.  but for low-latency connections (sub ms), and
sub 10gbe, it's not going to make a difference.

- erik

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

[erik quanstrom]

> A server can return responses in any order since each request
> has a client defined unique tag associated with it. Don't see
> why the same connection can't be used both sides to act as a
> server for the other....  Though this assumption may be
> implicit in code.

mnt driver only only keeps one outstanding per client, so
this point is moot without changes to the mnt driver.

- erik

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

[Bakul Shah]

On Wed, 15 Oct 2014 14:29:49 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> > A server can return responses in any order since each request
> > has a client defined unique tag associated with it. Don't see
> > why the same connection can't be used both sides to act as a
> > server for the other....  Though this assumption may be
> > implicit in code.
>
> mnt driver only only keeps one outstanding per client, so
> this point is moot without changes to the mnt driver.

Indeed. My point was that for "server push", you don't have to
extend the protocol, only implementations :-)

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

[Enrico Weigelt, metux IT consult]

Hi folks,

for contigious streaming, we could introduce a new TContRead op,
which tells the server to automatically send new data when available.

Maybe that could also carry some timestamp, so we can synchronize
different streams (eg. audio/video). Of course, this requires some
clear clock reference.

Servers which do not support that, would just reply Rerror, so the
client knows he should try simple TRead loop.

cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287