|Top Previous Next|
For the HTTP to work, you need to allocate some memory to the following buffers:
•RX buffer. This buffer will be receiving HTTP requests from the client (browser). Buffer allocation request is done through the sock.rxbuffrq method. It is possible to avoid spending memory on the RX buffer by redirecting this buffer to the TX buffer of the same socket. This will work because the web server operation is strictly sequential — receive a request, then generate a reply. Requests and replies do not have to be stored concurrently, so one buffer is sufficient and you will save some memory!
•TX buffer. This buffer will be handling web server replies. If you enable redirection it will also receive HTTP requests. Buffer allocation request is done through the sock.txbuffrq method. Practical experience shows that allocating just one page for this buffer makes HTTP request handling somewhat slow. At three or four pages, there is a significant performance improvement. Additional buffer pages do not lead to any dramatic improvements in performance.
•VAR buffer. Dynamic HTML pages include snippets of BASIC code and this code may need to know variable passed to the HTTP server using GET or POST methods. The VAR buffer stores those variables. Do the allocation with the sock.varbuffrq method. Buffer size of one page is usually OK. If the application is to handle large amounts of variable data, such as in the case of file uploads, you can improve the performance by allocating more pages.
Actual memory allocation is done through the sys.buffalloc method which applies to all buffers previously specified. Here is an example:
Memory allocation takes up to 100ms, so it is usually done just once, on boot, for all required buffers.
You may not always get the full amount of memory you have requested. Memory is not an infinite resource, and if you have already requested (and received) allocations for 95% of the memory for your platform, your next request will get up to 5% of memory, even if you requested for 10%.
There is a small overhead for each buffer. Meaning, not 100% of the memory allocated to a buffer is actually available for use. A certain number of bytes in each buffer is reserved for variables needed to administer this buffer. This number is 17 for 16-bit platforms and 33 for 32-bit platforms. Platform type is specified in your platform documentation.
Thus, if we requested (and received) a buffer with 2 pages (256 * 2 = 512), then we can only store 512 - 16 or 512 - 32 bytes in this buffer, depending on the platform type.