At present, the TCPClient and UDP classes allocate a static buffer - 128bytes for TCP and 512bytes for UDP.
I was thinking about changing these to be dynamically allocated or user allocated buffers to address issue 224 (user-defined UDP buffer size) and also to decrease the memory used by TCPClient, especially when used by TCPServer, which uses upto 3 buffers:
TCPServer declares a _client data member of type TCPClient as a placeholder for the last returned client instance. So TCPServer allocates a TCPClient buffer (128 bytes).
TCPServer assigns this _client member like this
_client = TCPClient(...)
Which potentially creates another buffer on the stack. Plus the TCPClient instance that the caller allocates and assigns the result of available() to, that’s potentially 3 buffers allocated.
If we changed TCPClient/UDPClient to use only a buffer pointer and a size, then only one buffer would need be allocated. A default constructor would allocate the default buffer size (using new) so existing code continues to compile and function as before. Additional constructors would allow the caller to provide the buffer they wish to use, so the buffer size can be tailored to the application.
I wanted to solicit comments before coding these changes - maybe there’s a reason this hasn’t been done already?
This makes sense to me, I’m guessing the reason it hasn’t been done yet is either to preserve arduino compatibility, or simply because we haven’t had a chance to implement it yet. @mohit or @satishgn might be able to weigh in on the issue since they’re more familiar with the firmware than myself.
Thanks @Dave, that’s what I suspected, but wanted to check to be sure! I look forward to hearing what the other guys have to say too.
And just in case it wasn’t clear, the changes I propose won’t break Arduino compatibility - existing code will continue to compile and run as before. But new code can take advantage of the caller-allocated buffers for more advanced use cases.
@mdma, it would be ideal to have dynamically allocated buffers for TCP/UDP stuff. Because of time constraints and other high priority stuff, such and similar other enhancements has been put on hold. Do let us know about your code updates on this topic!
Thanks
Satish
I was wondering if using dynamic memory was ok since I looked through the codebase and don’t see any use dynamically allocated memory so far - I know some teams go to great lengths to avoid it, but usually they have far less RAM afaik. Your confirmation sets me straight on that, thanks!
I’ll see if I can quickly code up dynamic memory allocation this evening and do a push request before I take my vacation!
