I get what you mean about the XDR now, you are manually transforming
your data using XDR then sticking it in the array? That makes sense :)
The "How much storage do you need?" wasnt meant as any sort of sarcastic
comment, was a serious question, pretty much all the limits in player
are set to the largest size that people have needed (plus a bit so they
dont need changed too often) what size do you recommnd? go for 1MB?
The image message is currently the largest in player (and just happens
to be 1080p HDTV resolution) so if you ever need to go above that you
would need to raise the player message size maximum.
Dynamic allocation would unfortunately make the client libraries more
complicated, particularly the c client library where data allocation
(and more importantly deallocation) cant be encapsulated in a class.
We could create allocate/deallocate methods for each structure type, but
whether the memory saving/flexibility would be worth the added
complexity probably would depend on how much of it all can be hidden in
the client libraries...
What are peoples thoughts?
Radu Bogdan Rusu wrote:
> Toby Collett wrote:
>> The max sizes are in raw data length not XDR data length so you can
>> store up to the full 1024 bytes. In theory nothing in player.h should
>> have any relation to XDR directly as XDR is an optional marshalling
>> library used with TCP (and I assume UDP)
> You can store 1024 bytes yes, but once you go through XDR, there will
> only be < 256 bytes of actual usable data. That's really easy to fill
> up. For instance, I was using one array of up to 10 floats (doubles were
> overflowing already :) ) in a structure which was being used up to 20
>> The only penalty of upping it is wasted memory allocation on the
>> server/client sides which generally isn't a huge problem unless you are
>> working on an embedded system. How much storage do you need?
> True, but we already have 1920*1080*4 for the camera image.
> You're right though, we should think about a more flexible allocation
> scheme. All these upper limits can be a bit painful.
>> Geoffrey Biggs wrote:
>>> Is XDR capable of handling a dynamically sized array? That would be more
>>> useful than a set size limit.
>>> Radu Bogdan Rusu wrote:
>>>> Thought I'd check with you before submitting a bug report.
>>>> /** Maximum message size is 1 MB */
>>>> #define PLAYER_OPAQUE_MAX_SIZE 1024
>>>> /** The data we will be sending */
>>>> uint8_t data[PLAYER_OPAQUE_MAX_SIZE];
>>>> So I cannot cram more than ~250bytes of data there (XDR-ed). Can we
>>>> "up it", pretty please? :)
>>>> I've defined a neat interface and wrote a couple of drivers for
>>>> automatic sensor data processing (like extracting features from
>>>> certain signals). I am currently only using it for WSN, but will
>>>> extend it soon to encapsulate various other types. This is really
>>>> useful if you're into machine learning, as raw values don't mean too
>>>> much there. Anybody else doing research in this area? I'd be happy to
>>>> exchange some ideas, and then maybe get this into Player (I'm using
>>>> lots of "opaques" right now, hence the above request).