Implement Telnet TIMING-MARK Option

[mystiker]

Description:
Implement support for the Telnet TIMING-MARK option to enable synchronization points in the data stream between client and server. This option is useful for measuring network latency and ensuring that specific points in communication have been reached, making it valuable for real-time applications where precise timing is required.

Details:

1. Option Code: 6

2. Functionality:

   • The TIMING-MARK option allows either the client or server to insert a timing marker into the data stream.
   • This marker serves as an acknowledgment point, confirming that all preceding data has been received and processed by the recipient.
   • The TIMING-MARK option is often used to measure round-trip time for network latency analysis or to ensure synchronization in high-reliability systems.

3. Expected Workflow:

   • Either the client or server sends IAC DO TIMING-MARK to request support for TIMING-MARK.
   • Upon receiving IAC WILL TIMING-MARK, the requesting side can periodically send IAC TIMING-MARK as a marker.
   • The other party should respond with an IAC TIMING-MARK, confirming that the marker has been received and signaling a synchronization point.

4. Acceptance Criteria:

   • The client successfully negotiates TIMING-MARK with the server.
   • The client can send and receive timing marks as synchronization points.
   • Round-trip timing is accurately reflected, allowing for latency measurements when needed.

References:

• Telnet RFC 860 (for TIMING-MARK option)

[mystiker]

Supporting TIMING-MARK requires intrusive handling of special IAC sequences, with no subnegotiation involved, making it hard to integrate smoothly with existing code. It would demand extra parsing logic just to detect and respond to IAC TIMING-MARK commands, which adds clutter to an otherwise clean data handling pipeline.

Consequently, we won’t be adding support for it. This option is implicit declined.

However, we might reconsider this IF we have another valid reason to parse the output data for IAC Commands.

[mystiker]

I’ve changed my mind and decided to implement the TIMING-MARK feature.

The client now responds to ping requests using the TIMING-MARK option as defined in RFC 860.
It was not necessary to extract IAC TIMING-MARK commands into a separate parsing logic. The feature works seamlessly through the existing negotiation framework without additional complexity.
This ensures clean integration while supporting synchronization points in the data stream.