I am working with M66 and BC660 and trying to align HTTPS access.
Normally I used QHTTP and QFILE to handle download of larger files (100KB), but since BC660 does not support QHTTP nor QFILE, I am trying to use QSSL.
I have it working on M66 and BC660, but there are some differences in the QSSL api.
On the M66 it is possible to tell how much data you want to receive, which is very nice. It makes it possible to make some “flow control”, and handle the data in smaller blocks.
But for some reason the QSSL api in BC660 does not have such a feature. Here the received data is sent as URC (Unsolicited Result Code), where the actual received data is also broadcasted. Therefore it is not possible to control how much and when to receive the data.
Can someone please help me to understand, if it is correct, that there is no way of handling flow control on BC660 module. It seems like BC66 has the same “limited” QSSL protocol.
Thanks
hi,BitProgress:
The BC660 does not provide flow control. The flow control function of the M66 is mainly caused by the fact that the data sending speed of the M66 is faster than that of the receiving end. If the receiving cache is nearly full, the receiving end stops sending data until the sending speed catches up with the sending speed or the receiving cache is available.
But if an application needs to receive e.g. 100KB of data, and store it in NVM memory, it seems strange, that a RAM buffer of 100KB (+ HTTP header overhead) is needed - instead of designing an API, where data can be received from module in chunks of e.g. 16KB - and them save these chunks on the fly to NVM.
The CPU memory of the module (BC660) will often be much larger, than the application processor.
Or at least I can think of a lot applications, where a smaller application CPU is sufficient, and then rely of the BC660 for doing the hard work…
Can you confirm, that my assumption for need of a way to throttle the SSL data is incorrect?
BR Martin
hi,BitProgress:
What application protocol do you plan to implement your flow control through, such as TCP, HTTP or MQTT?
Hi Herbert,
It is HTTPS.
The M66 is capable of it because here you are notified about new data via URC, which only tells, that some data is ready in a context/stream. The actual data is not received as part of the URC.
And then you ask to read the data, and here you are able to tell how much data, you want to read.
In that way you can throttle (and save data to NVS) just by calling “Receive” as fast or slow as you want.
BR Martin
hi,BitProgress:
I think the different modules have their own advantages, and if the corresponding module is suitable for our business needs, so you don’t have to pay too much attention to the details.