14 Feb, 2009, quixadhal wrote in the 41st comment:
Votes: 0
DavidHaley said:
I also get a little twitchy about live editing of a DB causing instant reflection of those updates in the MUD, and would also suggest some form of RPC instead if that goal is desired.


Well, the idea there is that you can use tools that are already designed to work with ODBC to interact with your data, and writing a web interface to interact with an ODBC data source isn't hard (at least in PHP). But yes, if you don't want the MUD to have to detect and react to such changes (either via notifies, or checking a dirty bit in the update loop), then you get to write your own tools and treat the database as read-only (by external clients) if your game is running.
14 Feb, 2009, David Haley wrote in the 42nd comment:
Votes: 0
Oh, I have no issue with reading live data using these database tools. What I'm not sure I understand is why you want external database tools to be writing back and expect things to happen reasonably. It seems that as a question of interface, something more aware of how things fit together would be far more efficient for editing. Even with the constraints placed on data etc., a generic DB-like interface to the MUD's data knows nothing about the bigger picture, and therefore cannot present things in a more efficient/informative fashion.
14 Feb, 2009, Tyche wrote in the 43rd comment:
Votes: 0
Stormy said:
Lobotomy said:
Lobotomy said:
Tyche said:
…with the exception of MCCP support. I didn't see any point in bothering with it.

Why?

Any chance I'll get an answer? :sad:


He addressed that here.


Sorry Lobotomy, I missed the question. Yes the above about covers it. It's something I wouldn't have included in a bare bones chat server. It's also something I never bothered including in any other muds I worked on.
14 Feb, 2009, Scandum wrote in the 44th comment:
Votes: 0
Tyche said:
Sorry Lobotomy, I missed the question. Yes the above about covers it. It's something I wouldn't have included in a bare bones chat server. It's also something I never bothered including in any other muds I worked on.

Smaller packets travel faster, so I'd say MCCP is always worth the trouble, especially for long distance connections.

I did some testing:

Mud A with MCCP:

Ping: Minimum = 146ms, Maximum = 203ms, Average = 168ms

Time to process area list:

327 msec
328 msec
328 msec

Mud B without MCCP:

Minimum = 106ms, Maximum = 122ms, Average = 113ms

Time to process area list:

561 msec
624 msec
687 msec

I'd say it's popular for a good reason.
14 Feb, 2009, Kline wrote in the 45th comment:
Votes: 0
Are Mud A/B the same game with MCCP enable/disabled? Or two separate games? If it's two separate games I'd argue the validity of your data.
14 Feb, 2009, quixadhal wrote in the 46th comment:
Votes: 0
Packet size (itself!) generally has no effect on TCP/IP transmission speed. The size of your data segment may vary, but if it's larger than the MTU on any given hop, your packet gets segmented and THAT is where larger chunks of data seem to take longer to travel, because they are broken into multiple packets and reassembled at the destination. Also, packets that are dropped (by error, or by the nagle algorithm) have to be re-transmitted, and that will also slow your connection. Smaller packets are less likely to be destroyed by error, so if your network is flaky, there may be some gain from that part of it.

A ping packet is 84 bytes (56 of which are data), and is generally of type ICMP, which a large number of network devices grant priority to these days. The typical MTU is around 1500 bytes, subtract off 20-60 for the header and you have 1400 left to play with. A full screen of text on a classic vt100 80x24 display is 1920 bytes.

I'd therefore suggest that the only place you'll see any noticeable gains from MCCP is when you actually have more than half a screen of text sent in one update loop. Possible in extra-spammy combat, probably more likely in a who list or similar. Even so, we're talking the difference between 2 or possibly 3 packets and 1 packet.

Also, by "process area list", do you mean the time between you typing "alist" (or whatever), and the time it finishes spewing the results back at you? That may be skewed by CPU load on the machine, network traffic on the machine's LAN (or the latter part of the route that's distinct), even disk access if the machine is swapping. At the very least, you'd want to compare traceroute output to see how many hops each site has between you and themselves, and probably do a who to see how many players are online.
14 Feb, 2009, David Haley wrote in the 47th comment:
Votes: 0
Indeed, the data is all but meaningless if the MUDs aren't on the same network, or at the very least very "similar" networks with comparable load, etc.

Although Quix is right about individual packets, more data being sent means more bytes to transmit, and less data being sent means fewer bytes to transmit, meaning that transmission time is reduced. It's worth noting that the origin OS is probably taking care to send packets that don't get segmented. (I'm assuming that by "packet" you don't mean chunk of data but actual network packet, given what you said later.)

But anyhow, fewer packets means almost trivially faster total data transmission, even if individual packets aren't necessarily moving faster.
14 Feb, 2009, David Haley wrote in the 48th comment:
Votes: 0
It occurs to me that MCCP can make SMAUG (and maybe all Dikurivatives) seem faster because the MUD server itself starts to "stutter" output if there is more than a certain threshold in the outgoing buffer. MCCP means that there is less data to be sent, and therefore you are less likely to go above that buffer. By "stutter" I mean that it stops sending out as much as it can each network update, and instead sends out some smaller fraction.
15 Feb, 2009, Scandum wrote in the 49th comment:
Votes: 0
I tested it again from the same server, and it looks like MCCP is indeed only a gain in the case of fragmentation.

I guess someone would have to test it on dial-up to see if it makes a difference.
15 Feb, 2009, David Haley wrote in the 50th comment:
Votes: 0
Don't forget that dial-up only affects the speed in between the user and their ISP, not the ISP and the MUD server. Assuming that Tyche is correct about dial-up users already having compression (and there is no reason to believe he is incorrect), dial-up users are basically already using a form of MCCP.

I still think that the main beneficiary of MCCP is the server, not the client… even small savings will add up over time, and can matter even instantaneously if the server's bandwidth is somewhat limited to begin with.
Random Picks
40.0/50