[Vortex] present user profiles only after securing connection

[Francis Brosnan Blazquez]

El sáb, 25-03-2006 a las 18:06 -0500, Philip Kovacs escribió:
> Francis,

Hi Phil!

> Besides taking advantage of the one-to-many response
> exchange type of BEEP, you also eliminate the need to run a separate 
> profile on the
> client-side.

I still think two separated profiles will be required, as you proposed.
This will allow you to implement the different logic required to process
replies received, for each profile.

While creating channels [1] you'll have to set a frame received handler
[2]. This handler will be fired once a reply (or a message) is received.

According to the design, only RPY messages should be received on the
frame received handler for the catalog profile and a series of ANS/NUL
messages for the stream profile.

> 
> The data stream definition/proposal will typically have, say, 100+ 
> different data points,
> with configuration information from the catalog.  

Ok.

> Once the proposal is 
> accepted by the
> server, the negotiation is essentially done.  Then the server's role
> is 
> to periodically take
> the samples, with no additional interaction from the client, and 
> transmit them.  So it's:
> 
> (server) forever:
> {
>    take a hundred different samples
>    format them
>    transmit them
>    (sleep interval)
> }

Ok.

> 
> Perhaps the way to approach this, as you say, is indeed to have the 
> client create the
> data channel and then, on that data channel, the client sends a
> single 
> msg, such as:
>  "BEGIN STREAM"   Then the server starts pumping ANS chunks back, over
> and
> over, until the a request is sent on the control channel to stop.  
> 

This is the idea. And, the way to stop the stream transmission, will
also do.

> Is it reasonable to run a single MSG->(ANS)+ exchange that might 
> continue indefinitely?
> MSG="start stream"
> ANS+="chunk of n samples"

Sure, and, as you proposed, once it is required to stop the
transmission, a message is sent over the control channel to stop. 

This will cause the above "server foreach" to issue a final NUL message
[3], making your client to have a clear beacon to know when the stream
transmission have definitely stopped. 

This won't be so easy for the MSG/RPY: this is because you never know if
there are more messages to come (every message received is independent
from each other).

> 
> I am assuming of course that I can use callbacks on the client when
> the 
> ANS frames
> arrive.

Sure. The way messages are received (not matter if they are
MSG/RPY/ERR/ANS/NUL) is to fire the same frame received handler [2]
configured for the channel. That is, there is no difference from
handling ANS/NUL or RPY. 

Then, inside this handler, it is required to implement a switch/if-else
to manage the frame received.

For your case, you could even have only one frame received, for your
client application, as follow:

void frame_received (VortexChannel *channel, 
                     VortexConnection *connection, 
                     VortexFrame *frame, 
                     gpointer user_data)
{
  switch (vortex_frame_get_type (frame)) {
  case VORTEX_FRAME_TYPE_MSG:
    /* ERROR: client should not receive MSG frames */
    break;

  case VORTEX_FRAME_TYPE_RPY:
    /* uhmmn...it seems a RPY for a catalog request has
       been received. Process the catalog information */
    process_catalog (frame);
    break;

  case VORTEX_FRAME_TYPE_ANS:
    /* it seems a sample has been received due to a 
       stream request */
    process_stream_sample (frame);
    break;

  case VORTEX_FRAME_TYPE_NUL:
    /* an streaming operation is being stopped, signal
       user application this event. */
    process_stream_stoped (frame);
    break;

  case VORTEX_FRAME_TYPE_ERR:
    /* ERROR: client should not receive MSG frames */
    break;
  }
  
  /* do to not unref the frame received on this function. If
     a permanent copy is required, the frame content must be copied
     or a frame copy must be done by using: vortex_frame_copy. */
  return;
}

This is because we are based on the fact that only RPY are received in
response to catalog queries and ANS/NUL are received because streaming
ongoing operations. However, you could also consider to use two
separated frame received handlers.

Cheers!

> 
> Phil

[1]
http://www.aspl.es/fact/files/af-arch/vortex/html/group__vortex__channel_g25d81a9493c1621782fbbab2284ae54a.html#g25d81a9493c1621782fbbab2284ae54a

[2]
http://www.aspl.es/fact/files/af-arch/vortex/html/group__vortex__handlers_gacf66e3c505613c74ec4618b5faa3fd6.html#gacf66e3c505613c74ec4618b5faa3fd6

[3]
http://www.aspl.es/fact/files/af-arch/vortex/html/group__vortex__channel_gbb7a645bc30c0153ab359023619ca99f.html#gbb7a645bc30c0153ab359023619ca99f

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