Inband-Related Buffers (CMD, RPL, and TX2)

Three buffers are required for inband message processing. On startup, these buffers are not allocated any memory, so you have to do it if you are planning to send and receive inband messages.

The CMD buffer — used to store incoming inband messages (we call them "inband commands"). Use the sock.cmdbuffrq method to allocate memory for this buffer. Usually, inband commands are not very long, so allocating a minimum space of 1 page is typically sufficient.
The RPL buffer — used to store outgoing inband messages (we call them "inband replies"). Use the sock.rplbuffrq method to allocate memory for this buffer. Again, inband commands are usually not very long, so allocating a minimum space of 1 page will probably be sufficient.
The TX2 buffer — used internally by the socket when inband commands are enabled. You don't have to do anything with this buffer other than allocate memory for it. We recommend allocating as much space as you did for the TX buffer. Allocation is requested through the sock.tx2buffrq method.

Actual memory allocation is done through the sys.buffalloc method, which applies to all buffers previously specified. Here is an example:

Tibbo BASIC

							dim b1, b2, b3, b4, b5 as byte
							 
							...
							'setup for other objects, sockets, etc.
							 
							b1= sock.txbuffrq(5) 'you need this buffer to send regular data
							b2= sock.rxbuffrq(5) 'you need this buffer to receive regular data
							b3= sock.cmdbuffrq(1) 'buffer for incoming inband commands
							b4= sock.rplbuffrq(1) 'buffer for outgoing inband replies
							b5= sock.tx2buffrq(5) 'same buffer size as for the TX buffer 
							 
							....
							 
							sys.buffalloc ' Performs actual memory allocation, as per previous requests
						

Actual 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.

A warning note icon. 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.