06 Feb, 2011, Kyuss wrote in the 1st comment:
Votes: 0
I am trying to do a port of libtelnet to C# (or at least use it as a guide) for my mud. I don't quite understand how the options are supposed to be setup in the telopts that are passed in. This is the example in the README:

static const telnet_telopt_t my_telopts[] = {
{ TELNET_TELOPT_ECHO, TELNET_WILL, TELNET_DONT },
{ TELNET_TELOPT_TTYPE, TELNET_WILL, TELNET_DONT },
{ TELNET_TELOPT_COMPRESS2, TELNET_WONT, TELNET_DO },
{ TELNET_TELOPT_ZMP, TELNET_WONT, TELNET_DO },
{ TELNET_TELOPT_MSSP, TELNET_WONT, TELNET_DO },
{ TELNET_TELOPT_BINARY, TELNET_WILL, TELNET_DO },
{ TELNET_TELOPT_NAWS, TELNET_WILL, TELNET_DONT },
{ -1, 0, 0 }
};


2nd column is the "us" (local) setting, 3rd column is the "him" (remote) setting. I understand the "us" setting, put WILL for the options you want to support and WONT for the options you dont support. I don't understand what is supposed to go into the "him" setting. You haven't done negotiation yet so you don't know what the remote side supports.
06 Feb, 2011, Scandum wrote in the 2nd comment:
Votes: 0
I think the telnet option specification should have a default state for each side, I'm not too sure though. So reading them might provide some insight.

The way I handled it in MTH (a public domain telnet handling snippet) is to have a fuzzy initial state until negotiations have begun.
06 Feb, 2011, Deimos wrote in the 3rd comment:
Votes: 0
I'm not familiar with that lib, but I would wager that those are the initial default states for server/client, respectively. The client doesn't have to respond to negotiations, and if they don't, you have to do something. Those defaults seem rather odd, though. Usually you wouldn't want to just assume MCCP/MSP/etc. support.
Random Picks
0.0/3