As the original write of the output sync, here is some background and my thoughts.
That code was originally put back in before the client/server split. At that time, any control of messages had to be done is the server - there was no client to do that task. This really makes it a bit of legacy code. I have a feeling if that code never existed and someone today suggested adding code to the server to collapse messages, most all the devs would say no way - do it in the client. The fact that the code already exists in legacy form really shouldn't change the decision making process much. No one has ever done an analysis on how much bandwidth different aspects of the protocol consume. My gut feeling is that in general play, it is the map updates that take the most, but inventory/floor updates could take a considerable amount of bandwidth in certain circumstances (depending on how much stuff is on the floor or in inventory). Analysis of the messages is a bit easier than most - one could take an expected number of messages per second times an average size, and get pretty close to actual bandwidth uses (there is some overhead in the protocol, so maybe add 10 bytes for that). So if you say that you might get 50 messages/second, and each is 50 bytes (including that overhead), that is 2500 bytes/second (or 25 Kb/sec). If you're on a 56Kb modem, that is a big hunk. If you're on any form of broadband, that is trivial. Now a harder question would be how much would the output sync reduce that to, and that would involve a lot more assumptions or setting up what the circumstance is. I don't know what number of folks who play still have 56K modems - I doubt too many, and I'm not sure how hard we want to design towards that group. That doesn't mean we should waste bandwidth, but if the choice was between adding a feature that makes the game better but uses more bandwidth or trying to make it playable for people with 56K modems, I'd rather add the feature. We've never realyl come up with what a minimum standard for play is. All that said, output sync is much less useful than it once was. It can only combine messages that are exactly the same. Lots of messages basically set the flag that they can not be combined (this could be because ordering is important, like in lists, and output sync could mess that up, or in some cases where we know that the message is not likely to be something that we can combine, like in the case of examining items). So the case it was most often useful was the attack messages. When it was written, there were perhaps half a dozen different attack messages (you hit %s, you hit %s hard, you smash %s, you miss %s). So if you're fighting the same type of creatures, or case a spell into a mob of them, it does a good job of combining messages. However, when the attack messages were added, now there are a lot of different attack messages. As such, it is much less frequent for it to be able to combine messages - while they may convey the same information, they are different messages so can not be combined. I don't really have a good fix for that. So just as a general case, the output sync has less use than it did when first written. If one cared a lot about bandwidth of messages, then one could basically move localization for server to client and just send the i18n message id (as an example, look at lib/i18n/messages.* - just send '209 <intval>' type of thing. Now at some of connecting, the client would have to get all the message strings, etc. I personally don't think that it would be worthwhile to do that. But if one was really concerned about amount of data used for transmitting messages, sending integers (a 4 byte int should be more than enough for all messages) instead of 30 byte strings would be much more efficient. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
