Gangplank uses the TIMING-MARK option in the TELNET protocol for end-to-end acknowledgements to implement LosslessDetach with standard TELNET clients. This option is designed explicitly for output synchronization, and can be used to determine conclusively that output has traversed the network and been received by the client. This allows the server to ensure that no output can be lost be the network without ending up in the detach review buffer. Perhaps lily could use the same mechanism, or a similar one.

For TELNET clients which understand the option, IAC DO TIMING-MARK will trigger a response of IAC WILL TIMING-MARK after the previous output has been displayed to the user's screen, or IAC WON'T TIMING-MARK if the client cannot determine whether the output has been displayed. Either way, a response proves that the previous output was received over the network by the client. Unlike most TELNET options, TIMING-MARK is stateless -- after an IAC DO TIMING-MARK/IAC WILL TIMING-MARK exchange, the client will respond again to another IAC DO TIMING-MARK. (Normal TELNET options are stateful; after an option is turned on by a DO/WILL or WILL/DO sequence, further DO or WILL "requests" are ignored to avoid loops.)

For TELNET clients which do not understand the option, the basic TELNET protocol rules require the client to respond with IAC WON'T TIMING-MARK (in this case meaning "I don't understand that option") for each IAC DO TIMING-MARK request received. Some broken clients remember that they refused the option once, and don't respond again. These clients violate the TELNET specificaton, but such clients exist in the real world, so the server must test for them by sending at least two TIMING-MARK sequences and making sure at least two come back before relying on the mechanism for end-to-end acknowledgements. (Testing this way will also identify clients that don't really try to follow the TELNET protocol, such as raw TCP clients.)

-- DevenCorzine - 03 Nov 2003
to top