Stephen Seo [Thu, 13 Mar 2025 08:27:39 +0000 (17:27 +0900)]
Minor fix, TODO comment
Recent changes caused a packet timeout to be either 1 second or double
the heartbeat interval time (the maximum of the two). This is kind of a
problem since packet timeout should be ideally decided based on the
peer's heartbeat interval time, not this instance's heartbeat interval
time.
Some "scaffolding" code should be added:
- Heartbeat packets should send the current instance's heartbeat
interval time.
- Max capacity of cached sent packets should be increased based on
the peer's heartbeat interval and the rate of received non-heartbeat
packets.
- Maybe have a function to tell UDPC the intended usage regarding
latency: focus on low-latency default behavior, or focus on high
latency low packet-send-rate behavior.
The current changes should be reverted on master and the new changes
should be held back for now until this is all set up.
Stephen Seo [Thu, 13 Mar 2025 03:07:21 +0000 (12:07 +0900)]
Add UDPC_set_con_timeout_millis(...)
Add new function to set the connection timeout time. By default, this
timeout time is 10 seconds. If a packet hasn't been received for this
duration, then the connection is considered "timed out" and is dropped.
Previously this time was a constant 10 seconds. This commit allows
changing the connection timeout time. However, it cannot be less than
the heartbeat interval time.
Stephen Seo [Sat, 22 Jul 2023 07:29:19 +0000 (16:29 +0900)]
Impl "RWLock" for use in TSLQueue
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.
Stephen Seo [Thu, 22 Jun 2023 04:25:26 +0000 (13:25 +0900)]
Impl "unsafe" versions of UDPC_atostr(...)
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).
Stephen Seo [Thu, 22 Jun 2023 03:39:11 +0000 (12:39 +0900)]
Conditionally use UDPC_atostr internally
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.
Stephen Seo [Wed, 21 Jun 2023 04:23:26 +0000 (13:23 +0900)]
Fix potential memory corruption bug
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.
Stephen Seo [Wed, 15 Apr 2020 10:49:17 +0000 (19:49 +0900)]
Change how UDPC_PacketInfo handles it's data
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.