The implementation of the TCP block in 'MootoothWorkspace2' is computationally very simple, as is desireable for any protocol stack elements designed to be used in an embedded system which could, potentially, have limited available processor time. Even the most conceptually complex parts of the system, such as the state machines for opening and closing connections, and the logic for determining which segment of a messge should be sent in the current packet, do not require significant amounts of calculation.
The memory requirements for the TCP block are comparatively (though artificially) high. In the current implementation there are nine 32-bit integers, two 'vcc_string's and one TCP_TCB (Transfer Control Block) structure required to store the current state of the system (connection status, sliding window positions, current sequence numbers, etc.), and these would be required in any implementation of TCP. The main inefficiency in memory usage, comes in the fact that seven fairly large TCP_Packet structures are required to be resident in memory throughout TCP's operation. These are required in order to send and receive all of the different categories of packets which may be received at various times during operation (i.e. ordinary message packets, acknowledgement packets, open/close information packets.), and many more would be required in order to allow TCP to be able to correctly retransmit packets. This number of packets is required in order to ensure that packet structures which are still in use in the system cannot possibly be overwritten with new data before they are completely finished with. These packet structures all have to be permanently resident in memory due to Whitebox C's lack of dynamic memory allocation. In a normal implementation, memory for these packets would simply be allocated when it was needed and then free'd later, so even though the number of packets sent would be the same, they would not all have to be permanently resident in memory, and the total memory footprint would almost always be lower than the VCC-based implementation.