Transmit EmberStrings or Bytearrays Exceeding 1k using libember_slim

[Arndt Stedler]

And here we go...

I ran into a problem using libember_slim: transmitting large Strings or bytwearrays that are bigger than 

#define EMBER_MAXIMUM_PACKAGE_LENGTH (1024)

When you init the memory using 

void berFramingOutput_init(BerFramingOutput *pThis,
                           byte *pMemory,
                           unsigned int size,
                           byte slotId,
                           byte dtd,
                           const byte *pAppBytes,
                           byte appBytesCount)
{
   ASSERT(pThis != NULL);
   ASSERT(size <= EMBER_MAXIMUM_PACKAGE_LENGTH);

   if(size > EMBER_MAXIMUM_PACKAGE_LENGTH)
      size = EMBER_MAXIMUM_PACKAGE_LENGTH;

   bzero(*pThis);
   berMemoryOutput_init(&pThis->base, pMemory, size);

   pThis->base.base.writeByte = berFramingOutput_writeByte;
   pThis->base.base.writeBytes = berFramingOutput_writeBytes;

   pThis->crc = 0xFFFF;
   pThis->slotId = slotId;
   pThis->dtd = dtd;

   pThis->pAppBytes = pAppBytes;
   pThis->appBytesCount = appBytesCount;
}

it will not allow you to allocate more than 1024 byte (ok, it will not use more than 1k). And a value is always tranmitted in one piece...

If the buffersize is reached any further byte will be silently dropped.

How did you solve this problem?

I did not find a solution but to write that part anew

[ChaosOptional]

Why whould you even attempt that?

[Hoffmann, Kimon (LAWO)]

Hi Michael,

> Am 20.11.2017 um 08:14 schrieb ChaosOptional <Michael...@web.de>:
>
> Why whould you even attempt that?

This is not a helpful comment in any way. According to the specification packets with more than 1024 payload bytes are not forbidden, so Arndt’s question is perfectly valid.

Regards,
Kimon

[ChaosOptional]

Well, in order to give an answer or advice, it is often good to know what the intention is behind the question. A simple "does not work, end of discussion" might not be very helpful if he needs more length...

[Arndt Stedler]

I apologize for beeing so unprecise...

Our logicEngine (at the moment only integrated part of Vistool) can connect (multiple) EmberProvider. It is using the libember_slim

I ran into the problem that some of the providers offer SDP-files (see RTSP) for RAVENNA Streams that MAY exceed 1k. (And YES it is a normal EmberParameter with a value of type "utf-8") (normally they are about 512 byte, by the way)

Unfortunately I encountered an abnormal Program Termination caused by libember_slim (throwError(303, "BerMemoryOutput capacity exceeded");)

see (ember.c line 170ff) : void ember_writeString(BerOutput *pOut, const BerTag *pTag, pcstr pValue) 

and (berio.c line 64ff.) : static void berMemoryOutput_writeBytes(BerOutput *pBase, const byte *pBytes, int count)

Second: In the current implementation the caller has to know how big the packages will be (AFTER S101 encoding); for there is no chance to change the FIRST_PACKAGE/LAST_PACKAGE bits in the Ember-Header. You have to know that in advance.

My post was more an information than a request.

I will now start to remove the integrated S101 encoding;for it is not useful.

In order to build conform packages (that will not exceed 1024 byte of unpacked S101 data) it is important to have the buffer in raw-form and add the Ember-header when you finally encode it using S101

And yes. when you build a provider, libember_slim is a good choice. You know exactl what you are sending and how big the stuff is.

But as a consumer you do not have  a clue of incoming data.

[ChaosOptional]

Hi,

I was afraid that SDPs would have been the cause of your problem...

While the slim lib was indeed more aimed towards providers, which generally have a close control over what they can send and receive, a consumer is a totally different creature by nature. 

Yet, extending the buffer size (not the S101 block size) should be possible at the discretion of the implementation.

cu,

Michael