//B = Byte. This is inside of a for loop processing the incoming buffer.
case TelnetState.Do:
doPositiveReply(b, true);
return;
case TelnetState.Will:
doPositiveReply(b, false);
return;
case TelnetState.Wont:
doNegativeReply(b, false);
return;
case TelnetState.Dont:
doNegativeReply(b, true);
return;
…….
public void doPositiveReply(byte b, bool local)
{
TelnetOption option = local ? session.LocalOption(b) : session.RemoteOption(b);
byte feedback = local ? TelnetSession.WILL : TelnetSession.DO;
//Ignore if we don't support it or it's already enabled.
if (!option.Supported || option.Enabled)
{
TState = TelnetState.Normal;
return;
}
//Since it's not enabled, and we're supporting, switch on!
if (!option.Queried)
Feedback(TelnetSession.IAC, feedback, b);
option.Enabled = true;
TState = TelnetState.Normal;
return;
}
public void doNegativeReply(byte b, bool local)
{
TelnetOption option = local ? session.LocalOption(b) : session.RemoteOption(b);
byte feedback = local ? TelnetSession.WONT : TelnetSession.DONT;
//Ignore if it's not enabled and we didn't ask.
if (!option.Enabled && !option.Queried)
{
TState = TelnetState.Normal;
return;
}
//Disable the option and such, just to make sure we're compliant.
if (!option.Queried)
Feedback(TelnetSession.IAC, feedback, b);
else
option.Queried = false;
option.Enabled = false;
TState = TelnetState.Normal;
return;
}
class TelnetOption
{
private bool queried, enabled;
public bool Enabled {
get { return enabled; }
set
{
enabled = value;
//Reset queried.
if (value)
queried = false;
}
}
public bool Supported { get; set; }
public bool Queried
{
get { return queried; }
set
{
queried = value;
//If we're asking for it we probably want to make sure we support it.
if (value)
Supported = true;
}
}
public TelnetOption()
{
}
public TelnetOption(bool support)
{
Supported = support;
}
}
To paraphrase it, Nick says that the server must do IAC WILL MXP in order for the client to turn on the option. The guy on the server side claimed this was wrong, that MushClient should accept IAC DO MXP and went on to add that since zMUD correctly interpreted this then he should too.
I have a big problem with this, but it may not be something I can do anything about, I guess. For one, I agree with Nick that IAC DO MXP does not seem like a valid interpretation of the RFC. While the client is "doing" some parsing when MXP is on it is in fact the server that is "DOing" the MXP code, the client is just responding to that fact.
Anyway, so I guess my question is, with all these lovely standards set by clients like zMUD, that cater to broken or bad interpretations, are there any other major quirks\mishandlings that somebody writing a client needs to be aware of? My own Session management keeps track of local options and remote options separately, so - for instance - in the case of the above thread, I would have internally checked to see if MXP was enabled remotely before attempting to parse any MXP tags out of the input. If that server had activated via DO, my interpretation would have turned MXP on locally. Obviously it isn't a big deal to check both, but i can see it leading to problems with options where directionality does matter (like echo). I don't want to have to make little patches for individual MUDs just because I, or they, do not understand negotiation.
I'm also a little unclear on how MUDs use go-ahead, as some seem to use it to terminate lines and others don't.
—
V