Allows to get the next frame received on the given channel due to channel start reply piggybacking or due to a frame received while using the function vortex_channel_queue_reply as a frame received handler. This function is used with vortex_channel_queue_reply to receive the message replies (in fact, all messages received). It also support returning the data received due to channel start piggybacking through vortex_channel_get_piggyback. If you would like to know more about the piggyback concept, check the following section to know more about how piggyback could improve your protocol startup. The idea is to use vortex_channel_queue_reply as a frame receive handler which queues all frames received on a queue. Then, every time vortex_channel_get_reply is called, a frame from the queue is returned. This allows to support, using the same code, to receive a message reply either as a piggyback or as a normal reply (and any other frame received). Let's suppose you are implementing a profile which could send an initial start message with the piggyback, so it is saved one round trip: "with one message, we send the start channel request, including the first message exchanged.". At the remote peer, the channel creation request, with a piggyback content, could be replied, using two, standard allowed, methods:
This leads to a source code problem at the client side that perform a blocking wait: "It is needed a way to get, not only the piggyback, but also the same reply not using the piggyback method." Because piggyback is closely related to the channel creation, and to avoid writing two different piece of code to manage both cases, you have two methods:
NOTE: The frame returned by this function have to be deallocated using vortex_frame_unref when no longer needed. This is an special case because all frames delivered with first and second invocation handlers are automatically managed, that is, deallocated when the frame handler scope has gone. Because examples are more clear, here is one:
// create a channel making all frames received, including the // piggyback to be received in a blocking way: VortexChannel * channel; VortexAsyncQueue * queue; VortexFrame * frame; // create the queue to be used to perform the async wait queue = vortex_async_queue_new (); // create the channel channel = vortex_channel_new (// the connection where the channel // will be created connection, // let vortex library to manage // the next channel number available 0, // use default channel close handling NULL, NULL, // set the frame receive handling vortex_channel_queue_reply, queue, // no channel creation notification NULL, NULL); // now wait and process all replies and messages received while (axl_true) { // get the next message, blocking at this call. frame = vortex_channel_get_reply (channel, queue); if (frame == NULL) { // timeout found, do some error reporting // and default action on timeout received. // // for our example, the default action is: // keep on reading!. continue; } printf ("Frame received, content: %s\n", vortex_frame_get_payload (frame)); // deallocate the frame received vortex_frame_unref (frame); }
|