|
Telnet Q
General Discussion
|
|
|||
|
Ok, So I have half a mud-client in processing ANSI codes. The Telnet thing is driving me a little nuts, though. I'm not so much confused with the state machine as I'm a little confused about the proper replies and I think I may be overthinking things. My first question is, should the client ever advertise anything? I can't really think of a good reason for the client to initiate any requests. Is this naive of me? On the server side I can see the string of (and keeping track of) all kinds of option requests, but I don't believe the client does - which would make things simpler. Another reason I'm a little confused is because the SourceMUD implementation doesn't seem to send any responses back at all, - though this fits the notion that a client would not make any requests so anything it receives is the tail-end of the negotiation. Possibly its also because it's 2am and i'll regret making a stupid sounding post in the morning. |
||
|
|||
|
|
Pretty much as I figured, it isn't nearly as complicated as I thought. I really should stop trying to code things of import after 11pm though, my brain doesn't work nearly as well. Good case for a modify button on posts though! :P |
||
|
|||
|
Heh  No reason to modify the post -- usually much more helpful to just post the answer. Then if someone else with a similar problems Googles and finds this page, he gets an answer. Everyone is happy. ^__^ I do generally find it way easier to implement _two_ state machines: one for telnet and one for ANSI/text. It's good layering design, if nothing else. Doing telnet "properly" is a bit complicated. Technically, for every single possible option (256 of them) you need to track whether the option is enabled or disabled... for both directions. (That is, a total of 512 booleans.) It's not hard to code at all that way. If you get a DO request when you already have an option enabled, just ignore it. Then your client and the server can't get into an infinite loop of sending redundant requests back and forth. The trickiest part is in understanding what DO and WILL mean. ZMP doesn't technically do it right by the spec (I may fix this in future revisions.) DO means "you start using this option" where-as WILL means "I'm going to use this option." That is, if you are using the BINARY option (for 8-bit transmission), if the client sends WILL BINARY, that means the client wants to send 8-bit data. The server replies with DO BINARY, but the server is not itself able to send 8-bit data. The server needs to send a WILL BINARY to the client, and the client has to respond with a DO BINARY. Kind of confusing, but there you go. |
||
|
|||
|
|
I see, So in the most technical sense then once the server sends out WILL ZMP and receives DO ZMP the client should really do the same, or get a DO ZMP request before sending ZMP Input, for instance. Yeah, thats kind of a pain. I had assumed that once the option is on it was a duplex understanding, the Q Option RFC makes a little more sense now. I swear, those writers were sometimes a little obtuse in their explanation. |
||
|
|||
|
|
Honestly, I figured out telnet by reading the source to the BSD telnet server many years ago. The specs kinda suck. |
||
|
|||
|
|
I think I have a reasonable implementation, but the sample gets mangled here. Hopefully the MudMagic people will find some holes. The sourceMud implementation helped a bit to get it figured out, plus this conversation, so thank you =D |
||