Re: Telnet and character-mode input...

From: moog (
Date: 09/13/95

> This brings up an interesting point --- the smarter the client is, the 
> less packet traffic is required. i.e. if the client knows a good deal about
> the mud, it can do a lot of the work that the mud does now. This is not without
> risk. If the client knows a lot about the mud, then it can be hacked
> and that information used to the players advantage. This was a common
> problem when I used to write netrek code. You wouldn't believe the hoops
> we used to jump through to verify that the user was using a clean client.
> The other problem with a client is that it forces your users to get
> (and keep the most current version of) the client, something lots of mudders
> may be unwilling to do. Well, enough babbling... the whole point is that
> making a useful client involves more than you might think... and a simpler
> client turns out to be a fancy text editor, perhaps not worth the trouble.

This is one of the reasons why I would love to write a diku-smart client.
One that can act as a 'slave' in a sense for certain functions
that a mud would normally process and then output to the character.
	* for muds that have an actual color parser that will
	  take a string such as "`b my string" and actually fill 
	  in the appropriate escape characters (`b signifies a
	  paticular character) locally, instead of having the mud do it
	  every time send_to_char, write_to_q, etc etc are called.
	* client handles things like gethostbyname() upon start, then
	  sends it to the mud. yeh, i know a glaring problem can happen
	  by someone packet spoofing what ever address they want.
	* have all editing functions handled locally and then sent
	  to the mud.  user can use their local editor to format,
	  spell check, and edit a string (would be great for olc).
	* client handle things such as arrow keys, larger command
	  histories, control sequences (clear screen, erase word,
	  etc etc).  this is a minor thing and something a lot of
	  pc/mac/x telnets or mud clients can handle. also be easy
	  to setup better display bars using something like curses
	  and have the mud only send update information.
	* client maintains small list of frequenlty visited room
	  descriptions in memory and the mud sends something
	  "RoomDesc|3001" instead of the entire description.
	  and the client displays.  Sketchy idea, but interesting.
	* text in/out compression. i believe mume has integrated
	  this with their 'multiple server' setup. a very quicky
	  compression algorithm would have to be used.

Just minor thoughts about the subject, despite _serious_ loopholes 
and questionable practicality.

This archive was generated by hypermail 2b30 : 12/07/00 PST