What does it take to implement a chat system in Python (Not asking for code just advice before I start my little project)

Chris Angelico rosuav at gmail.com
Fri Jul 19 13:56:44 CEST 2013

On Fri, Jul 19, 2013 at 9:25 PM, Jorgen Grahn <grahn+nntp at snipabacken.se> wrote:
> On Thu, 2013-07-18, Chris Angelico wrote:
> ...
>> You can certainly do your server-side programming directly in Python;
>> in fact, I recommend it for this task. There's no reason to use HTTP,
>> much less a web framework (which usually consists of a structured way
>> to build HTML pages, plus a bunch of routing and stuff, none of which
>> you need). All you need is a simple structure for separating one
>> message from another.
>> I would recommend either going MUD/TELNET style
>> and ending each message with a newline, or prefixing each message with
>> its length in octets. Both ways work very nicely; newline-termination
>> allows you to use a MUD client for debugging, which I find very
>> convenient
> It's definitely the way to go.  It's not just MUDs -- a lot of
> Internet protocols work that way.  Netcat is one popular client for
> talking to/debugging/testing such servers.  No doubt MUD clients too,
> but last time I did such stuff was in 1993, and I think I used telnet

Yeah. As I mentioned, I'm a MUDder with tens of thousands of online
hours on Threshold RPG[1], and have written several MUD clients; in
fact, I'm right now working on Gypsum (fun fun). The most common
internet protocols all:
* Involve a well-known TCP port and a single socket connection (apart from FTP)
* Begin with a one-line (usually) greeting from the server
* Have a line-based request-and-response system
* Have normal lines divided into "command" and "parameters" as per
shell commands
* (Usually) have an easy way to recognize success/failure, even
without understanding the whole response
* Are human-readable to the extreme
* Rely on lower-level protocols for encryption (eg TLS)

The mail trilogy (SMTP, POP, IMAP) are all like this, with the caveat
that IMAP tags commands and responses (so the second word, not the
first, is the command). FTP is almost there, apart from its secondary
data channel. MUDs are definitely right there. And when I started
putting together some networking facilities at work, I naturally
gravitated to this kind of system. Even when it's a purely internal
protocol, I like being able to just telnet/netcat to the service and
operate everything manually. To date, I think I've implemented five or
six such protocols within the suite at work, with only a couple of
systems done differently (one of them uses a PHP client, for
hysterical raisins, so it's done over HTTP).

Plus, it's great to be able to break out the MUD client at work
without getting in trouble for playing games on company time :)


[1] http://www.thresholdrpg.com/ if you'd like to join me! You'll be
made very welcome!

More information about the Python-list mailing list