While implementing an NTP client , I identified potential issues regarding the precision of NTP timestamp conversions and the implementation of the offset formula according to RFC 5905.
Steps to Reproduce:
1: Execute getCurrentTime() to fetch the time from time.google.com.
2: Observe the conversion logic for the 64-bit NTP timestamp using floating-point math.
3: Compare the calculated offset $\theta$ against standard NTP client implementations.
Proposed Changes / Fixes:
Precision: Switch from floating-point arithmetic to BigInt for 64-bit NTP timestamp bit manipulation to avoid IEEE 754 precision loss.
Performance: Use a constant NTP_EPOCH instead of repeatedly invoking new Date('Jan 01 1900 GMT') inside the parsing loop.
Robustness: Implement explicit error handling in socket.send and ensure socket.close() is called in all rejection paths to prevent potential memory leaks.
While implementing an NTP client , I identified potential issues regarding the precision of NTP timestamp conversions and the implementation of the offset formula according to RFC 5905.
Steps to Reproduce:$\theta$ against standard NTP client implementations.
1: Execute getCurrentTime() to fetch the time from time.google.com.
2: Observe the conversion logic for the 64-bit NTP timestamp using floating-point math.
3: Compare the calculated offset
Proposed Changes / Fixes:
Precision: Switch from floating-point arithmetic to BigInt for 64-bit NTP timestamp bit manipulation to avoid IEEE 754 precision loss.
Performance: Use a constant NTP_EPOCH instead of repeatedly invoking new Date('Jan 01 1900 GMT') inside the parsing loop.
Robustness: Implement explicit error handling in socket.send and ensure socket.close() is called in all rejection paths to prevent potential memory leaks.