[crossfire] Bug 2789515: output-count broken since 1.11 server

[Mark Wedel]

  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.