[Twisted-Python] Telnet MCCP Transport
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Sun Sep 5 09:49:08 EDT 2010
On 4 Sep, 01:19 pm, simonvermeersch at gmail.com wrote:
>I couldn't find an implementation of MCCP (Mud Client Compression
>Protocol) using Twisted so I made my own, which I'm sharing if anyone
>else has a use for it.
>You can find a description of MCCP here:
>Since I'm fairly new to Twisted I would appreciate any input about how
>to improve this if you find a better/cleaner way to do it.
>from twisted.conch.telnet import TelnetTransport
>from twisted.conch.telnet import DO, DONT
>COMPRESS2 = chr(86)
> def connectionMade(self):
> self.zlib = None
> def commandReceived(self, command, argument):
> if argument == COMPRESS2:
> if command == DO:
> self.requestNegotiation(COMPRESS2, "")
> self.zlib = zlib.compressobj()
> elif command == DONT:
> TelnetTransport.commandReceived(self, command, argument)
> def write(self, data):
> data = data.replace('\n', '\r\n')
> if self.zlib:
> data = self.zlib.compress(data)
> data += self.zlib.flush(zlib.Z_SYNC_FLUSH)
This approach has some drawbacks:
* Duplication of the logic in TelnetTransport.write. In this case, the
duplication appears to be imprecise: the original escapes IAC as well as
does newline translation, but your version only does the latter.
* If there's some other similar option you decide you want to support,
you'll probably have to implement it by adding the feature directly to
this class. Since MCCPTelnetTransport is a TelnetTransport subclass,
you won't be able to compose it with another similar class in any way
(either through inheritance or composition). This has slightly
unfortunate code re-use consequences.
* If you ever put a transport.write() call into connectionMade, I think
the result will be a corrupted transport (if the server supports MCCP).
This is because the bytes will be sent uncompressed because the server
will not have yet had a chance to send the DO COMPRESS2 response, so the
zlib object will not yet exist.
Only one idea really comes to mind for an implementation without (at
least some of) these drawbacks, and it may not really be worth the
trouble. The idea is that you would start off with an extra compression
protocol in the stack. It would act as a transport to TelnetTransport
and as a protocol to whatever lower level transport (eg tcp) you're
using. It would have methods for enabling and disabling compression
which you could call from your option negotiation methods.
* Since it would have a write method which sometimes compressed bytes
before passing them on, you wouldn't have to override
TelnetTransport.write, so you wouldn't have the duplication of code
* Since most of the code would be on a separate class, it *might* be
easier to re-use. Although since it creates a new interface that your
TelnetTransport subclass wants to use, this might not be true (you might
always need to use the two classes together, and they might break if you
inserted extra classes between them).
* It could buffer writes while negotiations were pending. Although you
could also just implement this yourself on MCCPTelnetTransport.
So, maybe a wash. It might just be better to fix the problems with your
current approach and move on.
More information about the Twisted-Python