Just looking under the stone that is Telnet option negotiation 🤢 and spotted that GMCP (ATCP, and 102) is(are) applicable in BOTH directions but it is not obvious that we actually negotiate it like that - e.g. we set enableGMCP as soon as we get either a DO or a WILL and do not negotiate BOTH directions as we ought as I understand it at the start HE (as SERVER) sends us a WILL to which WE (as CLIENT) reply DO and then enable the use of the option from HIM to US, however it is not obvious to me that WE (as SERVER) also sends a WILL separately to await HIM (as CLIENT) to replay with a DO/DONT in order for us to enable using the option from US to HIM... my head aches getting this clear in my mind 🤕
Also spotted KazDragon's Telnet library on GitHub which seems to be an active, up to date implimentation if we should ever decided to use a pre-packaged TelNet class.
cTelnet class with a pair of six-state enums to track each pair of options (HIM->US and US->HIM)...
DONT for all suboptions it doesn't know about
DONT for an option you do not understand is the correct response however this is mitigated by the user/a script registering an interest in the option with a Lua call to addSupportedTelnetOption(optionNumber) that sets a flag in (QMap<int, bool>) cTelnet::supportedTelnetOptions which changes that to a DO - mind you that only works for communications from HIM to US - it is down to the user/script to manage any negotiation for US to HIM (we send WILL option and await a DO back) - and I am not sure our code responds to that correctly as we then send another WILL in response to things that we understand...
however this is mitigated by the user/a script registering an interest in the option with a Lua call to addSupportedTelnetOption(optionNumber)
That's what I mean: I am not sure that telnet library is able to do that.
I have asked a question on SE lets see if I get any biters...
I think it does, the README points out:
>
activate()- this is used to request activation on the remote side.set_activatable()- this is used to allow the option to be activated from the remote side.on_state_changed- this is a signal that is called when the option is either being activated, active, being deactivated, or has become inactive.
WILL to request HE uses the option to SEND TO us
DO from HIM so we use option to SEND TO him
addSupportedTelnetOption (including callback to raise an event...)