Python's select behaves in the standard way (sit around until the timeout expires or data is ready or a socket is writable etc.). See, e.g., the manual entry on select. (Caveat lector: version 2.5, dunno if 2.6 changed something but I very strongly doubt it).

Python's is normal. I was referring to it blocking while waiting on data.

I'm not advocating hammering it just for the sake of it. In fact, I said the exact same thing about being expensive with enough rate and enough users. I fear this is turning into a bike-shed debate (edit) no, you were right.

so let's run some tests:

As fast as possible;

chat_server.py with full throttle polling, 0 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0  9588 3780 2324 R 99.8  0.4   0:06.72 python

chat_server.py with full throttle polling, 100 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0 10000 4052 2348 R 100.0  0.4   1:43.04 python

~100 times a second

chat_server.py with time.sleep(.01) in the game loop, 0 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0  9588 3816 2356 S  0.3  0.4   0:00.10 python

chat_server.py with time.sleep(.01) in the game loop, 100 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0 10012 4080 2376 S  6.6  0.4   0:02.90 python

chat_server.py with a .01 second Select() timeout, 0 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0  9588 3816 2360 S  0.3  0.4   0:00.07 python

chat_server.py with a .01 second Select() timeout, 100 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
20   0 10000 4036 2344 R  7.3  0.4   0:03.38 python

~ 10 times a second

chat_server.py with time.sleep(.1) in the game loop, 100 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
20   0 10140 4088 2380 S  0.7  0.4   0:00.56 python

chat_server.py with a .1 second Select() timeout, 100 users:

PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
20   0 10000 4076 2380 S  0.7  0.4   0:00.67 python

No suprise that constant polling is CPU wasteful. Using a timeout with Select vs. sleeping seems dead even. To be honest, I was not keen on hardcoding blocking into the server since I wanted to give all free cycles to Miniboa users. However, since blocking with Select() provides a superior user experience at low input rates and frees CPU usage on par with sleep(), I'll add it as a server variable. Plus, it's touch self-scaling in that total blocking time goes down as the input rate increases.

Committed revision 32.

Added a timeout property to TelnetServer(). You can specify it at creation;

telnet_server = TelnetServer(port=7777, address='', timeout=.05)

or change it on the fly. Default is 5 milliseconds.

I fully agree that you don't want the framework making strong policy decisions; you should always do just what you need, and not more. In this case though because the timeout is optional, the user gets to decide if they're fine with a (temporary, until-input-event) block. But yes, I completely agree with the hesitation to put in hard blocks.

Thanks for those figures.

I'm unclear as to the difference (in practice) between sleeping and using a select() timeout. Is it that the latter sleeps until there's activity while the former sleeps regardless?

It would be really nice if miniboa had built-in support for telnet character mode so neat stuff like this could be implemented:

http://dead-souls.net/ds-charmode-faq.ht...

It may be just as easy as adding client.char_ready (similar to client.cmd_ready) and client.get_character() (similar to client.get_command()) to the TelnetClient. Maybe not though, heh. I spent a bit looking for the telnet specifications for character mode, but didn't find much. Anyhoo, the main thing I'm trying to do with it is implement a wordstar-like editor for mudmails to get less of a MUD feel and more of a BBS feel. :)

EDIT:


You have it right. Select() will only wait the full timeout if there is no data received from clients while sleep() completely stops everything until it wakes up. I don't think that there's a HUGE difference between the two methods, in practice, though using a timeout in select() just "feels" more right to me. :)

Stoli summed it up well. I was not expecting the timeout to Select() to reduced CPU usage on par with Sleep() – so that combined with David's suggestion to make the timeout a user variable makes it a superior, easier option, especially for low input rates like your 10hz example. Even the default of .005 seconds reduces idle CPU usage on the hello_server.py example from 98% to .03.

If I get some time this weekend I'll look into it. I'd imagine sending the character mode IACs should be easy and just mimic how password mode works now. It does shift the burden of input handling to the coder, but that's what you want anyway.

I have my own MUD framework, but what I would like other people to write me loosely coupled libraries of supporting functionality :robot: :wink:. In that spirit, I've taken your 'telnet.py' file and made it into a library with only the telnet negotiation logic left (and edited it a bit).

I'm not 100% satisfied with the way it works with an encompassing framework, and it took me a lot longer to strip back than I would have liked, but it involved less reading of overly waffley RFCs, so thanks for that.

The idea of a repository for Python MUD code where standard decouplable functionality like this could be collected into libraries was one I was going to suggest. But other than this, I am not sure there is much else. Maybe an intermud-3 client. Maybe a simple BaseHTTPServer-based web server with comet support, and the required HTML, CSS and Javascript that it serves for a client front-end. Although these are somewhat more extensive and probably harder to cleanly decouple in shareable ways :thinking:.

This is the Telnet RFC for line mode: http://www.faqs.org/rfcs/rfc1116.html

My first guess was wrong. You don't 'turn off' line-mode to get character mode. You send the client a request to begin negotiating with IAC DO LINEMODE who responds with IAC WILL LINEMODE. From there, it's sub-negotiation blocks to set/acknowledge the mode via some masks. Making a little progress on my checked out copy.

Stoli, do you think you'd use character mode 100% of the time or switch back and forth?

If the MUD did intelligent things with character mode like tab completion etc., I'd see little reason to use line mode. In fact, unless there's some kind of bandwidth issue where you don't want to send too many individual packets, I'm not sure why you'd use line mode in particular in the first place.

I think the only reason to use line mode is if a given player wants to use a client that does its own editing/history/etc. However, if the mud implements proper terminal support (possibly even using termcap/curses), I doubt many would prefer a generic client's interface to one custom-designed and built into the actual mud itself.

Maybe this will be more helpful than the RFC.


I'm not sure that real LINEMODE (4 above) is used by many clients. Most every mud client will default into using kludge linemode (3 above).

What is the difference?

The difference is that one is an implicit mode (based on a 'guess') whereas the other is an explicitly negotiated mode.

I just noticed this…

For starters your signature is pretty big (a few lines is ok but 14 is a bit excessive), but does it really have to contain things like this?

See the link Barm posted in 31, and also http://www.faqs.org/rfcs/rfc1184.html

Edit: Rather RFC 1184 supersedes RFC 1131.

Well, line-mode makes for a clean demarcation point if you want to support completely different kinds of clients. For example, I've been toying with the idea of writing a Jabber server that would allow people to connect via instant messaging. Or maybe an ajax server for light web clients. These would be drop-in replacements for the client object I'm using now. That doesn't preclude providing a richer experience to Telnet users but it does make the code uncomfortably lopsided.

Secondly, I have a mental junk pile sitting behind me. It's things I was considering doing via Telnet that I scrapped after testing revealed that, collectively, MUD/Telnet clients really, really suck. Feature support is an awful, broken mess. Right down to little things like setting the background color. I just asked Tinyfuge to negotiate LINEMODE and got a WONT back. :sigh

I can see the usefulness of character mode though and I am interested in improving Miniboa. Right now I'm reading about how you can negotiate a table of values that special keys generate – which is pretty neat but, then again, I'm half afraid what testing with a dozen clients will reveal.

Thanks Tyche, that is helpful.



That's been my observation so far.