HTTP-related Buffers (RX, TX, and VAR)

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). Amount of buffer memory you allocate does not influence the maximum length of the HTTP request the socket will be able to process. We suggest that you allocate 1 page- this is absolutely sufficient. Buffer allocation request is done through the sock.rxbuffrq method.

•

TX buffer. This buffer will be storing HTTP replies being sent to the client. Again, amount of buffer memory you allocate does not determine maximum file size the HTTP server will be able to return. The server will happily work even with the smallest allocation of 1 page. Giving TX buffer more memory will improve performance, however. Buffer allocation request is done through the sock.txbuffrq method.

•

VAR buffer. Dynamic HTML pages include snippets of BASIC code and this code may need to know variable passed to the HTTP server together using GET or POST commands. The VAR buffer stores those variables. As will be explained later, there is no point in giving the VAR buffer more than 1 memory page. Do the allocation with the sock.varbuffrq method.

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.rxbuffrq(1) 'you need this buffer to receive HTTP requests

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

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

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 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. 16 bytes of each buffer are reserved for variables needed to administer this buffer, such as various pointers etc.

Thus, if we requested (and received) a buffer with 2 pages (256 * 2 = 512), we actually have 496 bytes in which to store data (512 - 16).

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.

Notice, 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, another one- to get the picture. We recommend that you reserve 4-8 sockets for the HTTP. It is better to have less buffer memory for each HTTP sockets than to have fewer HTTP sockets!