[Vortex] present user profiles only after securing connection

[Francis Brosnan Blazquez]

El sáb, 25-03-2006 a las 14:33 -0500, Philip Kovacs escribió:

Hi Phil,

> forever:
>      B sends MSG to A with data formatted for the profile.   A
> responds 
> positvely.   

I see, but, I have a question. Why do you want to acknowledge every
message sent from the server (using the interaction MSG/RPY)? Maybe you
want to ensure that data is comming in a proper way (no transmission
error)? 

However, no matter the pattern you use (MSG-RPY, starting from server to
client, or MSG-ANS/NUL starting from client to server), your data will
be delivered properly (we are running on top of TCP). 

I could only think about one reason to do this: client application can't
trust servers, so, a checkpoint is required on every piece received.
But, even on this situation, you can just drop the connection if the
server behaves badly (making the protocol you are designing to consider
a protocol violation to behave badly).

> 
> (some time later)
> A sends MSG to B on control channel asking to destroy data stream
> channel.
> B stops the datay stream, destroys the data channel.
> 
> See how the listener becomes the client?   That is different than the 
> one-to-many
> approach you suggest below.   

I see.

> The salient point is that the client A 
> does not
> initiate the data messages --- server A does, i.e. A becomes the
> client  
> for the
> data channel.
> 
> I hope this approach is sound.   I want the A client to "react" to 
> incoming data points
> (by firing callbacks).   I don't want A to continuously ask B to
> "send 
> data."

That's fine, but we have to consider three things:

1) It is a problem to do streaming on top of MSG/RPY. This is because
there are many round trips (every chunk is confirmed by a RPY, leaving
apart the problem of doing streaming on top of TCP, which is considered
by many network gurus a sacrilege. I'm not in such group ;-). 

2) If a MSG is sent from the server, by definition, the next MSG won't
be sent, even if you call to the API to do so, until the client replies
back, with an RPY, the previous message sent. Obviously this is a
problem because you have an imposed delay between every MSG sent defined
by the following round trip:
  
   a) Your MSG, from the listener side, must reach the client side.
   b) It has to be delived to the application level (which doesn't 
      happens inmediatly).
   c) Your client application level process it, and replies.
   d) The replies comes back to the server (which, again, doesn't 
      happens inmediatly, think about the other channels running).
   e) ...and now we can send the next MSG to the client..

3) The ANS/NUL design will allow your server to perform a reply as fast
as posible, sending every ANS message without wait to the previous.
You'll get better performance using this interaction pattern.

But, let's talk about using a more concrete example. From my
understanding (correct me if I miss something), you can initiate the
data stream channel, using the catalog information from the control
channel, by calling to the API this way:

<code>
VortexChannel * data_channel;

/* create a channel, by requesting that the transmission should
   be done using the binary format. This is done by using the
   piggyback support */
data_channel = vortex_channel_new_full (connection,
	0,    /* let vortex to chose the channel number */
	NULL, /* no serverName spec, at least, for the example */
	"http://phil-data-profile.com",
	EncodingNone, /* don't botter with the encoding */
	"binary",     /* piggyback the message "binary" */
	strlen ("binary"),
	....[channel handlers]...);
</code>

Now, if the server side accepts the channel to be created, accepting the
format indicated in the piggyback content, the server must reply to the
item requested to be streamed. 

Then, if the client request an item from the catalog to be streamed, it
only have to issue one MSG and a series of ANS messages, ended by a NUL
reply, will happen.

/* make the server to stream */
if (! vortex_channel_send_msg (data_channel,
	"<catalog><item>23</item></catalog>", 
	34,
	NULL)) {
	/* unable to start stream operation, do something */
}
/* stream operation started. */

Then your client application will be notified (by firing callbacks),
every time a ANS is received (including the last NUL), making your
client to not poll the server everytime, only once, that is, at the
begining of the operation.

Cheers!

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