Soliciting comments on a Telnet Protocol using tulip

[jeff quast]

Hello,

I'd like to share a Telnet Server implementation using tulip and request any feedback anybody anybody would like to share. I feel there may be facilities in tulip that I should be making use of... though it appears to function just fine. Any guidance of any wrong- or should-be-doings here appreciated.

https://github.com/jquast/telnetlib3/blob/master/telnetlib3.py

For instance, Implementing SLC_XON (^s) and XOFF (^q) required some sort of flow control on the writer.I subclassed both_SelectorSocketTransport and SelectorEventLoop to implement this. Is this correct? The _prefix indicates it isn't, but I couldn't find another way or example. Interesting that the reader has a pause() and resume() but not the writer. It looks like i've implemented the same on the other end of the socketpair, using a different pseudonym.

Telnet Servers are responsible for requesting various negotiation states for a wide variety of basic and extended options. If you connect to the example server with a bsd telnet client, the logger will blow up with a fascinating variety of option negotiations. Any generic interface would necessarily be rich with callbacks, and this library is no exception.

However, there is a general lack of fancy tulip expressions being used. No coroutines or futures, no yield from, just a very simple _negotiate() loop on connect that uses call_soon and call_later. Is this because I'm missing out on some interesting opportunities? Or because the telnet protocol lends itself to, or at least my implementation is strictly, byte-at-a-time processing? I feel as though these features are not necessary here ..

As mentioned about asyncore and pyftpdlib in prior discussions, With SO_OOBINLINE and MSG_OOB not implemented in tulip, it looks like the Protocol does not comply with the telnet RFC for the "Synch" mechanism.

If you escape ^] in bsd telnet client, and type "send synch" to the example server, The IAC byte is not received, and the "May have received DM ...." debug line is printed, by matching only DM, which, in BINARY mode, could just as well be an extended ascii character for whatever encoding.

I may use such a check to "snuff" it quietly, or receive it as part of input for the rare occasions it is received while in BINARY mode. Does this sound safe enough?

Although I haven't finished CHARSET negotiation, some support for byte encoding is offered. The default linemode will echo back any bytes received and may appear to be correct on output. For this same reason, if your "KEY_UP" sequence is equal to your visual "move_up" sequence, it appears like you may be moving your cursor in a full screen editor, but it isn't. You would expect the same behavior from a tcp echo server.

For now, typing "set CHARSET=utf-8" at the prompt will change the decoding to 'utf-8'. I soon plan to wire in CHARSET rfc, which I've seen some MUD clients reply "UTF-8" to (though not bsd telnet client).

Having previously authored a "Telnet BBS" system in python that behaves in "character at a time" mode, and previously implemented the same with twisted, and having extended for various NAWS, TTYPE, NEW_ENVIRON, etc, and having studied several other implementations out there over the past 10 years, esp. recently in a growing "Python Mud Server" community, I'd like to have this polished off onto pypy land and get these projects more compatible and more capable. I really want to see them stop being confused by encodings ! Some of these projects already use Twisted, so there is hopes they could "plug-in", as it goes.

I do hope to provide an examples folder with a perhaps a chat server, a basic mud game (that implements some additional mud-only telnet extensions), and maybe something like dgamelaunch that front-ends pty.fork() to demonstrate character-at-a-time, even if it is just /usr/games/trek or vi or something. I also aim to create a (headless) Telnet Client based on the same Protocol. Most of the Protocol code is shared between client and server, and enforced by 'is_server' assertions already. There is also a great deal of warnings and assertions regarding RFC compliance in place, as I hope to create a server fingerprinting tool, a capability-compliance testing tool, and perhaps a client-fingerprinting telnet server for honeypots.

Thanks always your feedback!
Jeff Quast
con...@jeffquast.com

[Guido van Rossum]

On Tue, May 21, 2013 at 4:21 AM, jeff quast <con...@jeffquast.com> wrote:
> Hello,
>
> I'd like to share a Telnet Server implementation using tulip and request any feedback anybody anybody would like to share. I feel there may be facilities in tulip that I should be making use of... though it appears to function just fine. Any guidance of any wrong- or should-be-doings here appreciated.

Hi Jeff,

Thanks for giving Tulip such a thorough try! It's a lot of code to
take in, so I'll focus on issues that directly affect Tulip.

> https://github.com/jquast/telnetlib3/blob/master/telnetlib3.py
>
> For instance, Implementing SLC_XON (^s) and XOFF (^q) required some sort of flow control on the writer.I subclassed both_SelectorSocketTransport and SelectorEventLoop to implement this. Is this correct? The _prefix indicates it isn't, but I couldn't find another way or example. Interesting that the reader has a pause() and resume() but not the writer. It looks like i've implemented the same on the other end of the socketpair, using a different pseudonym.

You found a hole in the spec and implementation. I was always aware
that we needed flow control in both directions, but didn't have much
of a use case for the other direction, so I waited for one to pop up.
You provided one. The PEP has this to say:

"""
TBD: Provide flow control the other way -- the transport may need to
suspend the protocol if the amount of data buffered becomes a burden.
Proposal: let the transport call ``protocol.pause()`` and
``protocol.resume()`` if they exist; if they don't exist, the
protocol doesn't support flow control. (Perhaps different names
to avoid confusion between protocols and transports?)
"""

However, it seems you've chosen a different implementation strategy,
probably because of the way telnet works: instead of the transport
asking the protocol to (temporarily) stop calling write(), in your
case the protocol asks the transport to to temporarily change
write()'s behavior to direct all data directly to the buffer and stop
flushing the buffer to the socket. That's actually an interesting
concept, as is the abort_output() method.

I propose that we add this functionality to the standard Tulip
StreamTransport classes, under different names. Could you come up with
a patch for that? I propose the following names: xon -> pause_writing,
xoff -> resume_writing, abort_output -> discard_buffer. (You can leave
the Proactor version unimplemented, although it should be pretty
simple to add it there too, if you have access to a Windows box to
test.)

In general, the _underscore_prefix classes are definitely not part of
the public interface, and subclassing them is the wrong way to go
about this -- if we weren't going to add these things to Tulip, I
would have recommended that you write some kind of adaptor class, or
add a buffer to the protocol class.

Which reminds me, I'm also not that keen on subclassing StreamReader.
In fact, I'm not keen on subclassing *any* classes that are provided
by a different library that aren't specifically written and documented
to support subclassing. Subclassing has its place (especially *within*
a library, as it is used by Tulip), but several decades of OO
programming have taught us that using subclassing as an approach to
API design is usually a bad idea. I suspect that if, instead of
subclassing StreamReader, you just write a separate class that takes a
StreamReader instance as an argument (or instantiates one, your
choice) your code wouldn't be much different, and there's much less
coupling between your implementation and the StreamReader
implementation.

> Telnet Servers are responsible for requesting various negotiation states for a wide variety of basic and extended options. If you connect to the example server with a bsd telnet client, the logger will blow up with a fascinating variety of option negotiations. Any generic interface would necessarily be rich with callbacks, and this library is no exception.

It's impressive. Did you just implement the entire RFC?

> However, there is a general lack of fancy tulip expressions being used. No coroutines or futures, no yield from, just a very simple _negotiate() loop on connect that uses call_soon and call_later. Is this because I'm missing out on some interesting opportunities? Or because the telnet protocol lends itself to, or at least my implementation is strictly, byte-at-a-time processing? I feel as though these features are not necessary here ..

I think it's fine. You're still using async I/O and an event loop.

> As mentioned about asyncore and pyftpdlib in prior discussions, With SO_OOBINLINE and MSG_OOB not implemented in tulip, it looks like the Protocol does not comply with the telnet RFC for the "Synch" mechanism.

Another thing for which I didn't have a use case. IIRC I asked Glyph
about these and he didn't think they were much used either. But it
sounds like full implementation of the telnet RFC requires supporting
these, and I'd be happy to comply -- except I don't know a thing about
how they are typically used (never having used them myself). But if
you send me even just a sketch for a patch, I'd be happy to look into
it and (probably) incorporate some version of it.

> If you escape ^] in bsd telnet client, and type "send synch" to the example server, the IAC byte is not received, and the "May have received DM ...." debug line is printed, by matching only DM, which, in BINARY mode, could just as well be an extended ascii character for whatever encoding.

Heh. I have no idea what you just wrote. :-(

> I may use such a check to "snuff" it quietly, or receive it as part of input for the rare occasions it is received while in BINARY mode. Does this sound safe enough?

Again, I'm not sure, because I don't understand. Is this feature
actually used? (TBH I haven't used telnet in ages -- it's all SSH
nowadays. :-)

> Although I haven't finished CHARSET negotiation, some support for byte encoding is offered. The default linemode will echo back any bytes received and may appear to be correct on output. For this same reason, if your "KEY_UP" sequence is equal to your visual "move_up" sequence, it appears like you may be moving your cursor in a full screen editor, but it isn't. You would expect the same behavior from a tcp echo server.

Again, I don't really understand what you are saying here.

> For now, typing "set CHARSET=utf-8" at the prompt will change the decoding to 'utf-8'. I soon plan to wire in CHARSET rfc, which I've seen some MUD clients reply "UTF-8" to (though not bsd telnet client).

Ah, I guess MUDs are the reason Telnet still exists?

> Having previously authored a "Telnet BBS" system in python that behaves in "character at a time" mode, and previously implemented the same with twisted, and having extended for various NAWS, TTYPE, NEW_ENVIRON, etc, and having studied several other implementations out there over the past 10 years, esp. recently in a growing "Python Mud Server" community, I'd like to have this polished off onto pypy land and get these projects more compatible and more capable. I really want to see them stop being confused by encodings ! Some of these projects already use Twisted, so there is hopes they could "plug-in", as it goes.

Sounds like a great case for Tulip!

> I do hope to provide an examples folder with a perhaps a chat server, a basic mud game (that implements some additional mud-only telnet extensions), and maybe something like dgamelaunch that front-ends pty.fork() to demonstrate character-at-a-time, even if it is just /usr/games/trek or vi or something. I also aim to create a (headless) Telnet Client based on the same Protocol. Most of the Protocol code is shared between client and server, and enforced by 'is_server' assertions already. There is also a great deal of warnings and assertions regarding RFC compliance in place, as I hope to create a server fingerprinting tool, a capability-compliance testing tool, and perhaps a client-fingerprinting telnet server for honeypots.

That sounds awesome.

> Thanks always your feedback!
> Jeff Quast
> con...@jeffquast.com

--
--Guido van Rossum (python.org/~guido)

[jeff quast]

On May 21, 2013, at 12:41 PM, Guido van Rossum <gu...@python.org> wrote:

> However, it seems you've chosen a different implementation strategy,
> probably because of the way telnet works: instead of the transport
> asking the protocol to (temporarily) stop calling write(), in your
> case the protocol asks the transport to to temporarily change
> write()'s behavior to direct all data directly to the buffer and stop
> flushing the buffer to the socket. That's actually an interesting
> concept, as is the abort_output() method.
>
> I propose that we add this functionality to the standard Tulip
> StreamTransport classes, under different names. Could you come up with
> a patch for that? I propose the following names: xon -> pause_writing,
> xoff -> resume_writing, abort_output -> discard_buffer. (You can leave
> the Proactor version unimplemented, although it should be pretty
> simple to add it there too, if you have access to a Windows box to
> test.)

Attached is a patch as described. I've changed the demonstration server to request a compatible client to send IAC XON/XOFF for ^s/^q and it appears to do work as expected.

> Which reminds me, I'm also not that keen on subclassing StreamReader.

Your right, I should have known better ala Twisted factories. I had a feeling it was amiss in this way, thanks for seeking it out.

>> Telnet Servers are responsible for requesting various negotiation states for a wide variety of basic and extended options. If you connect to the example server with a bsd telnet client, the logger will blow up with a fascinating variety of option negotiations. Any generic interface would necessarily be rich with callbacks, and this library is no exception.
>
> It's impressive. Did you just implement the entire RFC?

Thanks... As far as "entire RFC", I'm afraid there were several refinements. RFC 1123 lays out clear "must, should, may" language for a standards-compliant client and server. With an exception to DM, it is at least standards-compliance and then some. In comparison to the BSD C Telnet Server, only kerberos authentication and (likely weak) encryption is not implemented.

In short at least the following are implemented: RFC 854, 855, 856, 857, 858, 859, 860, 1073, 1079, 1091, 1096, 1184, 1123, 1372, 1572.

it's been interesting.. a few historical highlights -- early proposals included a curses-like capability strings negotiation (rfc 734) which RMS had some part in, or Byte Macro(rfc 735) could be used as a simple compression routine. I also learned about a strange authentication forwarding mechanism proposal, which was apparently used in a US-MIL radar simulation training system, which was accessed by Telnet.

>> As mentioned about asyncore and pyftpdlib in prior discussions, With SO_OOBINLINE and MSG_OOB not implemented in tulip, it looks like the Protocol does not comply with the telnet RFC for the "Synch" mechanism.
>
> Another thing for which I didn't have a use case. IIRC I asked Glyph
> about these and he didn't think they were much used either. But it
> sounds like full implementation of the telnet RFC requires supporting
> these, and I'd be happy to comply -- except I don't know a thing about
> how they are typically used (never having used them myself). But if
> you send me even just a sketch for a patch, I'd be happy to look into
> it and (probably) incorporate some version of it.

It is sketchy. I think to actually implement "Synch" would be only to entertain itself as a historical reference. I'd like to see something outside of ftp or telnet require it, but I haven't found one yet. This is leakage from '70s-era network protocols, like SNA.

And even though it is listed by 1989 RFCs as a "must", I've found only one modern client that can transmit it (bsd telnet), and it only does so by an explicit request from the user, not during any ^C or such signal.

I think the "Synch" mechanism is meant for single-process systems, which would include the tcp/ip stack in the same address space, to escape out (or into?) the telnet 'iac' byte parsing routine ..

>
>> If you escape ^] in bsd telnet client, and type "send synch" to the example server, the IAC byte is not received, and the "May have received DM ...." debug line is printed, by matching only DM, which, in BINARY mode, could just as well be an extended ascii character for whatever encoding.
>
> Heh. I have no idea what you just wrote. :-(

To reproduce sending the "Telnet Synch" mechanism using the bsd telnet client, after connecting (telnet localhost 6023), press Ctrl-], then enter command "telnet synch".

Client sends bytes telnetlib.IAC, telnetlib.DM, 'IAC' is sent with flag MSG_OOB, but only byte 'DM' is received by tulip (not OOB).

Going on to describe what I think a proper handling might be (with no OOB support in tulip), that, if BINARY is not negotiated, this 8-bit byte is certainly a DM, but otherwise, 99.9% of the time correctly presume it is just a high-bit ascii in whatever locale.

Regarding 'CHARSET', I should introduce the topic that telnet is strictly a 7-bit ascii protocol, with the exception of the command bytes. A telnet option BINARY is used negotiated to desire each parties' willingness to send 8-bit characters -- but the encoding used is implementation-dependent.

I plan to use the 'CHARSET' negotiation option to this effect. I've so far discovered Mud clients and Mud Servers use this option to send "utf-8" (the only encoding they appear to support).

In the meantime, the of the telnet session with this impl. can be changed using using the command 'set CHARSET=utf-8' with the demonstration server.

>> For now, typing "set CHARSET=utf-8" at the prompt will change the decoding to 'utf-8'. I soon plan to wire in CHARSET rfc, which I've seen some MUD clients reply "UTF-8" to (though not bsd telnet client).
>
> Ah, I guess MUDs are the reason Telnet still exists?

I'm as surprised as you are in regards to its continual use, it doesn't seem to have declined any in the past 10 years.

Some MUD authors/admins estimate as many as 40% of their users are vision impaired, that was an astounding figure to read. Some boast thousands of daily players (aardwolf.org appears to have ~400 right this moment), though I admit I've never been a MUD player, though I dos emulate a legacy BBS game 'LORD', which is rather MUD like, but just nostalgia really.

When looking into telnet encoding issues, I recently discovered a highly prevelant use of Telnet Bulletin Board systems in China and surrounding areas, mostly using GBK or BIG-E encodings... maybe SSH is illegal in China? The Freebsd manual shows a great screenshot of what it looks like for these folk: http://netlab.cse.yzu.edu.tw/~statue/freebsd/zh-tut/cxterm.html

Some folk have even made AI Bots that play the rogue-like nethack on the nethack.alt.org telnet 'competition server'. In fact, there was some discussion and implementation there regarding the long-lost GA ('Go-Ahead' signal) to better aid those bots. Many embedded or server room devices, (power monitoring, network edge devices) have been automated, monitored, or farmed of data using python and telnetlib(or twisted). .. it is only a matter of time until somebody wants to integrate django with their IBM 3270-client compatible mainframe server (disclaimer: i have no plans to support 'tn3270'!).

Regardless, its been a fascinating topic to research. I appreciate all of your feedback.

Thanks,
Jeff Quast
con...@jeffquast.com

[Glyph]

On May 21, 2013, at 3:28 PM, jeff quast <con...@jeffquast.com> wrote:

I think to actually implement "Synch" would be only to entertain itself as a historical reference.

This is why I mentioned that MSG_OOB is rather a historical curiosity.  In 15 years of fairly esoteric network programming, I've never run across anything that _actually_ needed it, and all indications are that it doesn't really work.

-glyph

[Guido van Rossum]

On Tue, May 21, 2013 at 3:28 PM, jeff quast <con...@jeffquast.com> wrote:
> On May 21, 2013, at 12:41 PM, Guido van Rossum <gu...@python.org> wrote:
>
>> However, it seems you've chosen a different implementation strategy,
>> probably because of the way telnet works: instead of the transport
>> asking the protocol to (temporarily) stop calling write(), in your
>> case the protocol asks the transport to to temporarily change
>> write()'s behavior to direct all data directly to the buffer and stop
>> flushing the buffer to the socket. That's actually an interesting
>> concept, as is the abort_output() method.
>>
>> I propose that we add this functionality to the standard Tulip
>> StreamTransport classes, under different names. Could you come up with
>> a patch for that? I propose the following names: xon -> pause_writing,
>> xoff -> resume_writing, abort_output -> discard_buffer. (You can leave
>> the Proactor version unimplemented, although it should be pretty
>> simple to add it there too, if you have access to a Windows box to
>> test.)
>
> Attached is a patch as described. I've changed the demonstration server to request a compatible client to send IAC XON/XOFF for ^s/^q and it appears to do work as expected.

Awesome. The only quibble I have is the name of the '_xmit' instance
variable, but I can fix that myself. Have you signed the PSF
contributor form yet?

(I now also wonder if the existing pause/resume methods shouldn't be
renamed to pause_reading and resume_reading. I'll ponder this a bit
more.)

>> Which reminds me, I'm also not that keen on subclassing StreamReader.
>
> Your right, I should have known better ala Twisted factories. I had a feeling it was amiss in this way, thanks for seeking it out.
>
>>> Telnet Servers are responsible for requesting various negotiation states for a wide variety of basic and extended options. If you connect to the example server with a bsd telnet client, the logger will blow up with a fascinating variety of option negotiations. Any generic interface would necessarily be rich with callbacks, and this library is no exception.
>>
>> It's impressive. Did you just implement the entire RFC?
>
> Thanks... As far as "entire RFC", I'm afraid there were several refinements. RFC 1123 lays out clear "must, should, may" language for a standards-compliant client and server. With an exception to DM, it is at least standards-compliance and then some. In comparison to the BSD C Telnet Server, only kerberos authentication and (likely weak) encryption is not implemented.
>
> In short at least the following are implemented: RFC 854, 855, 856, 857, 858, 859, 860, 1073, 1079, 1091, 1096, 1184, 1123, 1372, 1572.

Wow. Jaw-dropping wow. Definitely belongs on PyPI!

> it's been interesting.. a few historical highlights -- early proposals included a curses-like capability strings negotiation (rfc 734) which RMS had some part in, or Byte Macro(rfc 735) could be used as a simple compression routine. I also learned about a strange authentication forwarding mechanism proposal, which was apparently used in a US-MIL radar simulation training system, which was accessed by Telnet.
>
>>> As mentioned about asyncore and pyftpdlib in prior discussions, With SO_OOBINLINE and MSG_OOB not implemented in tulip, it looks like the Protocol does not comply with the telnet RFC for the "Synch" mechanism.
>>
>> Another thing for which I didn't have a use case. IIRC I asked Glyph
>> about these and he didn't think they were much used either. But it
>> sounds like full implementation of the telnet RFC requires supporting
>> these, and I'd be happy to comply -- except I don't know a thing about
>> how they are typically used (never having used them myself). But if
>> you send me even just a sketch for a patch, I'd be happy to look into
>> it and (probably) incorporate some version of it.
>
> It is sketchy. I think to actually implement "Synch" would be only to entertain itself as a historical reference. I'd like to see something outside of ftp or telnet require it, but I haven't found one yet. This is leakage from '70s-era network protocols, like SNA.
>
> And even though it is listed by 1989 RFCs as a "must", I've found only one modern client that can transmit it (bsd telnet), and it only does so by an explicit request from the user, not during any ^C or such signal.
>
> I think the "Synch" mechanism is meant for single-process systems, which would include the tcp/ip stack in the same address space, to escape out (or into?) the telnet 'iac' byte parsing routine ..

Ok. Well, I still don't quite understand what synch is, but it sounds
like you're not pushing for a new Tulip feature to support it, so I'll
let it go.

>>> If you escape ^] in bsd telnet client, and type "send synch" to the example server, the IAC byte is not received, and the "May have received DM ...." debug line is printed, by matching only DM, which, in BINARY mode, could just as well be an extended ascii character for whatever encoding.
>>
>> Heh. I have no idea what you just wrote. :-(
>
> To reproduce sending the "Telnet Synch" mechanism using the bsd telnet client, after connecting (telnet localhost 6023), press Ctrl-], then enter command "telnet synch".

Sadly I have no setup where I can actually try this...

> Client sends bytes telnetlib.IAC, telnetlib.DM, 'IAC' is sent with flag MSG_OOB, but only byte 'DM' is received by tulip (not OOB).

Ok, I get it. Well, I guess we just won't support that.

> Going on to describe what I think a proper handling might be (with no OOB support in tulip), that, if BINARY is not negotiated, this 8-bit byte is certainly a DM, but otherwise, 99.9% of the time correctly presume it is just a high-bit ascii in whatever locale.

Yeah, you can't mess with binary data.

> Regarding 'CHARSET', I should introduce the topic that telnet is strictly a 7-bit ascii protocol, with the exception of the command bytes. A telnet option BINARY is used negotiated to desire each parties' willingness to send 8-bit characters -- but the encoding used is implementation-dependent.

The notion "8-bit character" is rather outdated anyway in this age of
Unicode... I've been trained not to call the bytes of an encoded
string characters. Ever.

> I plan to use the 'CHARSET' negotiation option to this effect. I've so far discovered Mud clients and Mud Servers use this option to send "utf-8" (the only encoding they appear to support).

Makes sense.

> In the meantime, the of the telnet session with this impl. can be changed using using the command 'set CHARSET=utf-8' with the demonstration server.
>
>>> For now, typing "set CHARSET=utf-8" at the prompt will change the decoding to 'utf-8'. I soon plan to wire in CHARSET rfc, which I've seen some MUD clients reply "UTF-8" to (though not bsd telnet client).
>>
>> Ah, I guess MUDs are the reason Telnet still exists?
>
> I'm as surprised as you are in regards to its continual use, it doesn't seem to have declined any in the past 10 years.

Probably won't until that generation starts dying in significant numbers. :-)

> Some MUD authors/admins estimate as many as 40% of their users are vision impaired, that was an astounding figure to read.

But what does vision impaired mean? I wear glasses. Do I qualify?

> Some boast thousands of daily players (aardwolf.org appears to have ~400 right this moment), though I admit I've never been a MUD player, though I dos emulate a legacy BBS game 'LORD', which is rather MUD like, but just nostalgia really.
>
> When looking into telnet encoding issues, I recently discovered a highly prevelant use of Telnet Bulletin Board systems in China and surrounding areas, mostly using GBK or BIG-E encodings... maybe SSH is illegal in China? The Freebsd manual shows a great screenshot of what it looks like for these folk: http://netlab.cse.yzu.edu.tw/~statue/freebsd/zh-tut/cxterm.html

Maybe the most prevalent hardware there is just much older / weaker,
and of necessity runs older software -- probably pirated versions of
Windows XP.

> Some folk have even made AI Bots that play the rogue-like nethack on the nethack.alt.org telnet 'competition server'. In fact, there was some discussion and implementation there regarding the long-lost GA ('Go-Ahead' signal) to better aid those bots. Many embedded or server room devices, (power monitoring, network edge devices) have been automated, monitored, or farmed of data using python and telnetlib(or twisted). .. it is only a matter of time until somebody wants to integrate django with their IBM 3270-client compatible mainframe server (disclaimer: i have no plans to support 'tn3270'!).

Heh.

> Regardless, its been a fascinating topic to research. I appreciate all of your feedback.

Fascinating read!

Let me know if I can be of any service.

> Thanks,

[Nikolay Kim]

On May 22, 2013, at 10:29 AM, Guido van Rossum <gu...@python.org> wrote:

> On Tue, May 21, 2013 at 3:28 PM, jeff quast <con...@jeffquast.com> wrote:
>> On May 21, 2013, at 12:41 PM, Guido van Rossum <gu...@python.org> wrote:
>>
>>> However, it seems you've chosen a different implementation strategy,
>>> probably because of the way telnet works: instead of the transport
>>> asking the protocol to (temporarily) stop calling write(), in your
>>> case the protocol asks the transport to to temporarily change
>>> write()'s behavior to direct all data directly to the buffer and stop
>>> flushing the buffer to the socket. That's actually an interesting
>>> concept, as is the abort_output() method.
>>>
>>> I propose that we add this functionality to the standard Tulip
>>> StreamTransport classes, under different names. Could you come up with
>>> a patch for that? I propose the following names: xon -> pause_writing,
>>> xoff -> resume_writing, abort_output -> discard_buffer. (You can leave
>>> the Proactor version unimplemented, although it should be pretty
>>> simple to add it there too, if you have access to a Windows box to
>>> test.)
>>
>> Attached is a patch as described. I've changed the demonstration server to request a compatible client to send IAC XON/XOFF for ^s/^q and it appears to do work as expected.
>
> Awesome. The only quibble I have is the name of the '_xmit' instance
> variable, but I can fix that myself. Have you signed the PSF
> contributor form yet?
>
> (I now also wonder if the existing pause/resume methods shouldn't be
> renamed to pause_reading and resume_reading. I'll ponder this a bit
> more.)

one note for patch. we should check if self._buffer is not empty before self._loop.add_writer()

[Glyph]

On May 22, 2013, at 10:29 AM, Guido van Rossum <gu...@python.org> wrote:

Ah, I guess MUDs are the reason Telnet still exists?

I'm as surprised as you are in regards to its continual use, it doesn't seem to have declined any in the past 10 years.

Probably won't until that generation starts dying in significant numbers. :-)

We have attempted, in Twisted, to make it easier to spin up a MUD using the SSH protocol so that people can use that instead of TELNET, but the annoyances of key management have made that harder than we would like it to be.

-glyph

[jeff quast]

On May 22, 2013, at 1:29 PM, Guido van Rossum <gu...@python.org> wrote:

> Have you signed the PSF contributor form yet?

I've just signed under 'jquast', thanks.

>>> Ah, I guess MUDs are the reason Telnet still exists?
>>
>> I'm as surprised as you are in regards to its continual use, it doesn't seem to have declined any in the past 10 years.
>
> Probably won't until that generation starts dying in significant numbers. :-)
>
>> Some MUD authors/admins estimate as many as 40% of their users are vision impaired, that was an astounding figure to read.
>
> But what does vision impaired mean? I wear glasses. Do I qualify?

Anybody who uses speech assisted software, such as http://www.linux-speakup.org/spkguide.txt qualifies as a vision impaired user by that statement, this figure estimate was from a forum topic of mud developers, discussing why so many of their users prefer no-color/terminal-sequence-free options.

There is wide variety of hardware, or hardware-assisted devices, ala the famous 'DECtalk' device that Stephen Hawking used, but one thing is in common among all screen readers or speech synthesis software: they work best with line-oriented software. I can't imagine many other computer games to be very engaging to hear spoken to you by Stephen Hawking :)


I'm always watching Karl Dahlke's OSS work, who happens to be a blind and very capable C programmer. He wrote a web browser, 'edbrowse', which provides an ed-like interface to the web. It fascinates me to consider how his dev environment operates.

Jeff Quast
con...@jeffquast.com