#134 Future update isReady TRUE/FALSE to uint64_t

[Pharos Team]

As the RTN (Real-Time Network) library is created to allow TCP/IP connections with channels (to maximize speed), a point is raised on the TCP RFC 793:

"Users should receivepositive acknowledgments for buffers which have been SENT and fully acknowledged".

Don't know if this is implemented in Linux/Windows API. I mean, of course, the kernel knows what segments have been fully acknowledged and therefore received by the remote address, but as far as I known, the application has no way to know this since the API does not export this information.

Available or not in Linux/Windows, I believe this is a nice-to-have and there is no reason why this should not be implemented in RTN.

There could be some solutions to do this, (e.g. RTN could send back some information regarding how many bytes have been received by the remote address) but the way that seams the most "elegant" solution is for the application to send a channel bulk with the TX data and with that, a future.

Now, that future could be made "ready" after it is transmitted (for the first time) by the Ethernet/Wifi/whatever driver. For UDP this makes sense. For TCP, it would be nice to have it made "ready" for the transmission but also for the reception on the remote address (via the ACKs). Furthermore, there are other protocols (e.g. PUS) that have ACKs for even more states:

• reception (remote address has received the packet)
• acceptance (remote address has received checked that the packet contains valid information)
• progress (remote address has processed "x" percentage of the packet)
• processing (remote address has fully processed the packet)

So instead of the future being "ready" or "not ready", it could have an internal state with a uint64_t variable. The future is initialized with "0" and as the ready call is made with an extra argument (state):

PharosFutureReadyR pharosFutureReady(ptrFutureId id , ptrFutureArg arg ,  uint64_t state , ptrChannelBulk bulk)

the state can only increase:

future->state = MAX(future->state , state);

the wait and waitQueue calls will have an extra argument (min) with the minimum state:

PharosFutureWaitR pharosFutureWait(ptrFutureId number , ptrFutureArg arg , ptrChannelBulk bulk , uint64_t min , Timeout timeout)

PharosFutureQueueWaitR pharosFutureQueueWait(ptrFutureId futureDone , ptrFutureArg arg , ptrChannelBulk bulk , uint64_t min , Timeout timeout)

and will only return success if the future->state >= min.

For the PUS case, the uint64_t could be used with 1 for the transmission of the packet, 2 for the reception, 3 for the acceptance, between 3 and "UINT64_MAX-1" for the progress and UINT64_MAX for the fully processed.

For TCP, the uint64_t could be used with 1 for the transmission of the packet and 2 for the reception.

Note: the application can send the channel bulk with or without the future, so if it does not care about the transmission/reception/whatever of the packet then it just not uses the future.

[Pharos Team]

updated test 1100 with error conditions and level check
updated test 1110 with error conditions and level check
updated test 1130 with error conditions and level check for future queue
updated test 1140 with level check for future queue in complex situations
updated test 10220 for multi-core test with partial ready and then complete ready