PB v6.21: Network Library TLS (All OS)

[mk-soft]

I have adapted my NetworkTCP to TLS.

With TLS:
Here I have noticed that the #PB_NetworkEvent_Data event does not come through properly for the client.
Although data is already or still available in the receive buffer, the event #PB_NetworkEvent_Data is not triggered.
This means that the event is not triggered until further data has been received.
The event will probably arrive on the server side.

Without TLS:
In this case, sending and receiving runs smoothly

Here are two examples for server and client without TLS, server and client with TLS:

OneDrive: NetworkTCP Test Code

[idle]

Can you zip it, so it can be downloaded in one go?

[mk-soft]

Ok
Now one zip ...

[mk-soft]

Not a bug, but missing information about TLS

With TLS, the receive buffer must be at least as large as the send buffer.
Everything must always be read from the receive buffer at once. Partial reading from the receive buffer is not possible.
With macOS, the TLS send data is divided into 16 kB blocks and with Windows and Linux into 32 kB blocks.

If receive error -2 occurs, the read can be repeated

[idle]

The docs need updating and you really should recover from eagain to keep the connection open
Bailing out on -1 error is just wrong even if it worked but with tls if you don't flush it will break it. 90% of the time the network error is eagain / wouldblock which is just telling you to slow down, not close the connection.

Did you try the network continue function?

[HeX0R]

With TLS, the receive buffer must be at least as large as the send buffer.

I don't think this statement is correct (how should the receiver know the buffer size of the sender?), but idle is right, there are uncountable codes in the boards which are using network functions with bad/no error handling.
And yes, I agree, with TLS support it got even more challenging.

[mk-soft]

Without TLS you can also read out a part of the reception buffer with ReceiveNetworkData and again comes an event that still has data in the reception buffer. With TLS, there is no more event.

[idle]

The problem is that when you get the equivalent of Eagain in the TLS stack it resets the error and returns -2 or -3 for wants pole in and wants pole out which tells you to delay and call again.
It's why I wrote the Network Continue function with the send receive functions to act as replacements for sendnetworkdata and recievenetworkdata, before I was having problems which required me to look for content length and it was all because I wasn't acting on -2 or -3 properly at the time when I though I was, dyslexia is a pain in the neck. see what I think not what's actually there.

Also I have had to revert to my TLS implementation again, which may or may not be a PB issue, but I still have to use the tls wrapper to facilitate the TLS terminating reverse proxy and the TLS constants needed an adjustment to work with the pb static lib which may have lead to the issue I encountered which was failing to do a TLS handshake from httprequest where it has to revert to TLS 1.2 which is what httprequest -> curl -> schannel uses. I will have to come up with a test for the native implementation to see if it's a problem or not.