• Is there a reason the network buffer for sending is so small:

    It's that CC3000 needed a big static buffer to send the data (which I wanted to be as small as possible), but I think on non-CC3000 builds we could change that. If we could be sure the send function was only called from idle (I think it might be?) we'd be safe to allocate quite a large amount of data on the stack for that array.

    The 500-odd bytes you talked about as the limit for packets on that ESP8266 build sounds good.

    Why does clientRequestWrite in socketserver.c not kick off any transmission?

    I think it's because when using GSM or ESP8266 via AT, JavaScript gets called to do the write - and so we don't fill the stack up it makes sense to do that on idle. People also tend to use multiple writes, when realistically you want to send in as few chunks as possible so you want to group writes together.

    I don't understand github.com/espruino/Espruino/blo­b/master/libs/network/socketserver.c#L66­0

    Yes, that looks wrong - and a potential memory leak. I'm not sure why that hasn't caused problems before... It'd be interesting to see if we could trigger it with some code. I guess an HTTP chunked POST should do it?

    the intermingling of HTTP into plain sockets is not exactly clean.

    No... My reasoning was:

    • There is still quite a lot of duplicated code in each and I was desperately trying to get code size down
    • I wanted as few lists of sockets in memory as possible, so it made sense to stick them all in together and handle them as one.

    But yeah, it was more of an issue before I abstracted out all the socket stuff, it seems a bit more pointless now.

    I think MQTT should still be a JS module, as it currently is - the main addition would be WebSockets and UDP, but I think those should actually fit in quite well.

About

Avatar for Gordon @Gordon started