This reverts commit cf27a6bb76.
The use of "shared_lock" in TSLQueue is unsafe because of two things:
- The TSLQueue iterator takes a "read" lock.
- The TSLQueue iterator can erase the current element.
This project supports C++11, and std::shared_lock was made available in
C++17, thus a "shared_spin_lock" was created with similar functionality.
This "shared_spin_lock" is used in TSLQueue.
These "unsafe" versions are guaranteed to not have the returned address
strings be overwritten by UDPC, but they must be manually free'd later
(as mentioned in the documentation).
Previous implementation used UDPC_atostr() frequently. This commit
changes the implementation to only call UDPC_atostr() if the log level
of the code logging to output will cause the log to be output.
UDPC_atostr(...) uses a uint32_t as an offset into a buffer inside the
UDPC Context such that there can be at most 32 different addr-strings.
The call is thread-safe, up to a point (at most 32 concurrent calls will
return correct strings). The problem was that the offset was not being
reset to 0 and was always being incremented by 40. Should the offset
overflow, the offset into the buffer will be "mis-aligned" such that the
32nd offset into the buffer can possibly overwrite memory past the
buffer's end if the addr string is long enough.
The fix is to use a mutex instead of an atomic uint32_t to lock a
code-block that will always prevent overflow (using modulus operator).
I think the speed-loss is negligable (using a lock instead of an atomic
uint32_t) since it isn't expected for programs using UDPC to use
UDPC_atostr(...) very frequently.
Previously, ids could only be created with an ip address. Now they can
be made with a hostname, which will be looked up by UDPC.
Also fix client still requesting connections even if
accept-new-connections flag is false.
The "data" member variable in UDPC_PacketInfo is now handled as a
pointer to dynamic data, instead of an array with a fixed size. Every
time a UDPC_PacketInfo is received from the context,
UDPC_free_PacketInfo() must be called on it to avoid a memory leak.
Previous implementation had the client send only epoch-time-in-seconds
to be signed by the server. Now the client sends random data and
epoch-time to be signed by the server.
Stephen Seo