4 ms·

Wow, that's a huge effort and codebase! Congratulations for releasing it! I like the consistent coding style, the fact that cmake is used, and that sanitizers a

Wow, that's a huge effort and codebase! Congratulations for releasing it! I like the consistent coding style, the fact that cmake is used, and that sanitizers are used! I see the title mentions embedded systems. What systems are target of the SDK besides embedded linux? I looked for some kind of platform abstraction layer which would be useful for that, but couldn't find it so far. But actually not sure whether it would be worthwhile at all to run something like WebRTC on a MCU with a RTOS. Protocols that complex often require a ton of dynamic memory, which is not that compatible with the common no-allocation policies on embedded platforms.

Sean-Der 7y ago
Thank you! I actually don't know the embedded world at all. My background is WebRTC/userland programming. My answers aren't going to be great, but this is where my learning is at today :) > What systems are target of the SDK besides embedded linux I had a few conversations with embedded devs and they said if I wrote this in Pure C (and avoided GCC-isms) it would work well for. Most of the people I have worked with so far are doing embedded Linux, a few are doing non-Linux but I just get bug reports from them. They tell me their C compiler chokes on this etc... > I looked for some kind of platform abstraction layer We have a library called PiC[0] that does some of that. I don't think it is as low level as you are thinking though! It has portable atomics, and allows people to provide their own allocators stuff like that. > not sure whether it would be worthwhile at all to run something like WebRTC on a MCU with a RTOS Yea I think it would be pretty hard. Getting usrsctp and OpenSSL on those devices seem pretty insane. I have looked at OpenSSL alternatives, but for usrsctp I think we will need to solve it ourselves. I want to explore bringing down the footprint more, but the project is really driven by customer demands and no one has explicitly asked yet. [0] https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/tree/master/kinesis-video-pic/src/utils/src https://github.com/awslabs/amazon-kinesis-video-streams-prod...
- yc-kraln 7y ago
  There are a few widely-used embedded SSL stacks, of which mbed TLS is probably one worth targeting or adding support for (wolfSSL is another.) So long as this requires OpenSSL it's gonna basically be stuck in Linux.

Sean-Der 7y ago

Thank you! I actually don't know the embedded world at all. My background is WebRTC/userland programming. My answers aren't going to be great, but this is where my learning is at today :) > What systems are target of the SDK besides embedded linux I had a few conversations with embedded devs and they said if I wrote this in Pure C (and avoided GCC-isms) it would work well for. Most of the people I have worked with so far are doing embedded Linux, a few are doing non-Linux but I just get bug reports from them. They tell me their C compiler chokes on this etc... > I looked for some kind of platform abstraction layer We have a library called PiC[0] that does some of that. I don't think it is as low level as you are thinking though! It has portable atomics, and allows people to provide their own allocators stuff like that. > not sure whether it would be worthwhile at all to run something like WebRTC on a MCU with a RTOS Yea I think it would be pretty hard. Getting usrsctp and OpenSSL on those devices seem pretty insane. I have looked at OpenSSL alternatives, but for usrsctp I think we will need to solve it ourselves. I want to explore bringing down the footprint more, but the project is really driven by customer demands and no one has explicitly asked yet. [0] https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/tree/master/kinesis-video-pic/src/utils/src https://github.com/awslabs/amazon-kinesis-video-streams-prod...

yc-kraln 7y ago
There are a few widely-used embedded SSL stacks, of which mbed TLS is probably one worth targeting or adding support for (wolfSSL is another.) So long as this requires OpenSSL it's gonna basically be stuck in Linux.