Limited message length

[Tomáš Šoltys <to...@gmail.com>]

Hi all

I have slightly modified an example send.c file to send message containing
1024 bytes.
Above will result in zero sized message on the receiver side.

Is this an intention or a bug?

Regards,

Tomáš Šoltys

Re: Limited message length

[Fraser Adams <fr...@blueyonder.co.uk>]

On 15/05/14 13:28, Tomáš Šoltys wrote:
> Hi all
>
> I have slightly modified an example send.c file to send message 
> containing 1024 bytes.
> Above will result in zero sized message on the receiver side.
>
> Is this an intention or a bug?
>
> Regards,
>
> Tomáš Šoltys
I doubt there's a *deliberate* limit ;-) , my money is that the issue 
you're observing is actually on the receiver side. I've just tried 
sending an 11K string using the JavaScript binding I'm working on and 
that transfered OK.


Assuming that you are using recv.c in examples the bit of code that will 
interest you is:

char buffer[1024];
size_t buffsize = sizeof(buffer);
pn_data_t *body = pn_message_body(message);
pn_data_format(body, buffer, &buffsize);

format takes the encoded data and displays it in a human readable 
format, you pass in a buffer and you get the actual number of bytes back 
in the reference parameter - in this case buffsize.

As you can see in recv.c the buffer is a *fixed* 1024 byte buffer.

A more robust implementation would use a dynamically allocated buffer 
and check the return value of pn_data_format for PN_OVERFLOW and resize 
the buffer.


FWIW here's the implementation of format I've used in the JavaScript 
binding - it's somewhat relevant as it the binding actually 
cross-compiles proton-c to JavaScript so I need to handle the C style 
memory allocations in order to create something idiomatically JavaScript.

/**
* Format the encoded AMQP Data into a string representation and return it.
* @method format
* @memberof! proton.Data#
* @returns {string} a formatted string representation of the encoded Data.
*/
_Data_['format'] = function() {
var size = 1024; // Pass by reference variable - need to use setValue to 
initialise it.
while (true) {
setValue(size, size, 'i32'); // Set pass by reference variable.
var bytes = _malloc(size); // Allocate storage from emscripten heap.
var err = _pn_data_format(this._data, bytes, size);
var size = getValue(size, 'i32'); // Dereference the real size value;

if (err === Module['Error']['OVERFLOW']) {
_free(bytes);
size *= 2;
} else {
var string = Pointer_stringify(bytes);
_free(bytes);
this._check(err)
return string;
}
}
}

So as you see I'm checking for OVERFLOW and if I see it I free the 
original buffer and try again with a buffer of twice the size. The 
Python and Ruby bindings do pretty much the same.


As it happens as I was typing this I actually tried messing a bit more, 
when I sent a string of length 22277 it seems to be received OK but my 
producer doesn't seem to be terminating correctly, when I double it 
again to 44554 I don't seem to be receiving. That's quite possibly a bug 
in my binding - this is the first time that I've tried something so 
large however I have seen the odd
[0x550ef8]:ERROR amqp:connection:framing-error connection aborted
[0x550ef8]:ERROR[-2] connection aborted

and the underlying implementation is proton-c so it is possible that 
there's an issue there, I don't know how far the core proton-c testing 
has gone with respect to large messages, somebody like Rafael Schloming 
would hopefully know.

HTH,
Frase