Make built-in TLS play fair to TCP #3143
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Handshake functions in Mongoose TLS assumed data was being fully sent after calling mg_io_send(). This was in fact the case with the usual 1460-bytes MSS, but not with the default 536-bytes MSS.
This PR removes all those calls from individual handshake functions, actual send is done at the main handshake function, keeping track of the amount of data sent, and so handling small MTUs/MSSs and possible MG_IO_WAITs when running over a socket layer.
There's still a corner case that will be addressed on an upcoming PR: When a client is establishing TLS, if the call to send FINISH fails to send all data, outstanding handshake data will remain in c->tls->send. Assuming the client application will send something when the connection has been established, this data will be sent along with the customer data. This is maybe the most common scenario. Otherwise, data will stay in that buffer and the connection will stall.
Something similar to the above can also happen when the last piece of encrypted data can't be sent (either whole or in part), c->send.len = 0 and c->tls->send won't be flushed, situation that replicates with MbedTLS and OpenSSL, and so will be addressed on the aforementioned upcoming PR.