Re: RRMessage questions.

[email protected] (Jonas Borgström) 05 Dec 2002 15:44:46 +0100
Newsgroups gmane.network.beep.roadrunner.general
Message-ID <[email protected]>
Francis Brosnan Bl=E1zquez <[email protected]> writes:

> Hi.
>=20
> Cool. I have made a new profile using the template profile. It works
> really good. Well, here go my questions:
>=20
> What is the main difference between a RRMessage and a RRFrame? and if
> I'm going to use roadrunner to transfer files, do I need to split them
> in a fixed size to send them on RRMessage (or RRFrame maybe?) to get a
> good performance?.
>=20

You don't have to select a fixed size, RoadRunner will calculate the optimal
size for each frame. See max_size below.

> At the moment, I'm using RRMessage class to send my files and I'm
> splitting them in 1k fixed message. Must I do this or RoadRunner carry
> on with this stuff?.

RRFrame is a lower lever way of sending messages and should probably never
be used directly.

Using RRMessageStatic is the simplest way of sending messages, but it only
works when you can have the entire message stored in memory, so it can't be
used to transfer arbitrary sized files.

The solution is to create a new message class that inherits from RRMessage
and implements the "get_frame" function. This way you can implement you
own message class that supports streaming.

When you send your message with rr_channel_send_message (channel, msg, erro=
r)
RoadRunner will call your "get_frame" function (in you message class)
until the complete message has been sent.
Your "get_frame" function should then create a RRFrame that is <=3D max_siz=
e=20
bytes long. max_size is the last parameter in the get_frame function and
contains the maximum number of bytes the channel is currently allowed to
send (the number of bytes left in the channels send window).

If "get_frame" (for some reason) feels that it can't send just now because
max_bytes is to small, it simply returns NULL and waits for a bigger=20
window size.

This might sound complicated, but it might help to look at the
RRIDXPMessage class included in the idxp profile. It supports both
static and streamed messages.

http://rr.codefactory.se/cgi-bin/viewcvs.cgi/idxp/librridxp/rridxp-message.=
c?rev=3D1.11&content-type=3Dtext/vnd.viewcvs-markup


The default behavior for a RoadRunner channel is to aggregate all incoming
parts of a BEEP message to a single large RRFrame before calling=20
frame_available, but this doesn't work if the messages can be very large.
This "feature" can be disable like this:

rr_channel_set_aggregate (channel, FALSE);


One other thing. If you are using the CVS version of RoadRunner=20
(and future releases) you have to do this in the init function of each=20
RRMessage derived class.

message->type =3D RR_FRAME_TYPE_MSG;

RoadRunner need to known which message type the message will be before
the first "get_frame" call to do the out queue reordering correctly.

/ Jonas
--=20
Jonas Borgstr=F6m                  [email protected]
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 14