Fix incomplete reads in read_secure_message() by properly handling partial TCP payloads && README updates
#56
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.




Minor Logic Change
There was a bug in the
read_secure_message()API whereSST_SECURE_COMMmessages were not being fully read from the socket.After reading the message header, the implementation is supposed to read the exact number of bytes indicated by that header. However, the previous code called only a single
sst_read_from_socket()call, which retrieves only whatever data happens to be buffered at the TCP layer. Since TCP does not guarantee that an entire payload will arrive in one read, the function often returned incomplete message bodies when data is flooding.This PR introduces a simple loop that continues reading from the socket until the full number of bytes specified in the header has been received.
README updates.
As mentioned in #55, bullet 1 and 2, I updated the README files to be more descriptive.
I created a README under the
examples/, with a high level explanation of all examples, and the mainREADMEpoints this file.Directory name updates
Update
scenario_exampletoSST_Testbedas mentioned in #55. However, didn't change the structure yet.