[Vortex] present user profiles only after securing connection

[Francis Brosnan Blazquez]

El vie, 24-03-2006 a las 12:33 -0500, Philip Kovacs escribió:

Hi Phil,

> My interest is in developing an API for streaming real-time sampling 
> data back to clients.

This sounds really good.

> I would create a custom "control" channel, e.g. BEEP channel 1, over 
> which I can interrogate
> my servers for catalog information.    I then "subscribe" to data
> points 
> of interest, indicate
> desired sampling frequencies, etc. and ask the server to create a
> data 
> channel back to
> the client.  The messages on the data channels are data sample
> messages. 
> My "control"
> channel allows me to add/remove/alter data samples on the streams, 
> create new data channels,
> destroy them, etc. 
> 
> So the model I am looking at implementing is: one control channel 
> client->server and n data
> channels server->client.  In fact it's very similar to the "active"
> ftp 
> model, except of course it's
> all over a single BEEP session.
> 
> I think I will actually need two profiles.   Each client with need a 
> data sink profile and each server
> will need a data source profile.  The client seeks out the servers
> data 
> source profile, configures
> a data channel, and then the server connects back to the clients data 
> sink profile.

I think you have pretty much clear what you want to build and your
overall design looks good. 

I could only add (and maybe you have already take it into account) that
should use use the ANS/NUL for the profile used to send data back from
server. 

The idea is, once the client have choosen the source to stream, using
the calatog information supported by the first profile, a channel is
created, using the second one, that is, the data profile (maybe the best
entity to do so is the client), where the client request a stream
operation to start by issuing a MSG, making your server to reply with a
series of ANS message, finally ended by a NUL message.

It doesn't matter who starts the data stream channel. The key point is
that the client must be the one issuing the MSG request, to make the
server to start the streaming reply with ANS/NUL.

The other factor that you have to solve is how you are going to stop the
stream operation, because a cancel request have been received. 

Keep us updated with your progress Phil,

Nice day!

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.