HTTP-Related Buffers

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). The 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. The 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 Tibbo BASIC/C code and this code may need to know the variables passed to the HTTP server using GET or POST methods. The VAR buffer stores those variables. Do the allocation with the sock.varbuffrq method. A 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:

Dim f As Byte

...

'setup for other objects, sockets, etc.

'setup buffers of sockets 8-15 (will be used for HTTP)

For f=8 To 15

   sock.num=f

   sock.txbuffrq(1) 'you need this buffer for HTTP requests and replies

   sock.varbuffrq(1) 'you need this buffer to get HTTP variables

   sock.redir(PL_REDIR_SOCK0 + sock.num) 'this will allow us to avoid wasting memory on the RX buffer

Next f

....

sys.buffalloc ' Performs actual memory allocation, as per previous requests.

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 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 bytes), then we can only store 512 - 17 or 512 - 33 bytes in this buffer, depending on the platform type.

If you are changing the size of any buffer for a socket using sys.buffalloc and this socket is not closed (sock.statesimple is not PL_SSTS_CLOSED), the socket will be automatically closed. Whatever connection you had in progress will be discarded. The socket will not be closed if its buffer sizes remain unchanged.

Note that, in most cases, you will need to reserve more than one socket for HTTP. The HTTP server may need to service multiple requests from different computers at the same time. Even for a single computer and a single HTML page, more than one socket may be needed. For example, if your HTML page contains a picture, the browser will establish two parallel connections to the sock. object — one to get the HTML page itself and another one to get the picture. We recommend that you reserve four to eight sockets for HTTP. It is better to have less buffer memory for each HTTP socket than to have fewer HTTP sockets!