Kevin Bulgrien | 7 Aug 06:31 2009
Picon
Picon

Bug 2789515: output-count broken since 1.11 server

For those interested, see the SF tracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=2789515&group_id=13833&atid=113833

This is fair warning that the server support for output-count and output-sync
functions is about to be removed rather than fixed.

Ragnor states that jxclient already implements message folding in the client.

After looking over the server code, it seems quite clear to me that mwedel's
suggestion to move it to the client is a good idea.

My plan at the moment is to have the server continue to save the output_count
and output_sync fields to the player file, but to otherwise completely remove
references to any of the code and declarations that supported the facility.
The player save function would simply write the old defaults in to the player
file so that an older server would run sanely on the player file even if it
had been saved by the modified server.  A comment will be placed there saying
that this should/could be removed when the server goes 2.x.

Comments welcome.  The changes are sitting in my SVN checkout, but I'll hold
back a bit in case there is any life out there that cares.

Kevin
Juha Jäykkä | 7 Aug 12:24 2009
Picon
Picon

Re: Bug 2789515: output-count broken since 1.11 server

> After looking over the server code, it seems quite clear to me that
> mwedel's suggestion to move it to the client is a good idea.

Do you have any idea how this affects the latency on longer network links and 
when there are huge numbers of messages flowing? The output-count helped me a 
lot sometimes.

> Comments welcome.  The changes are sitting in my SVN checkout, but I'll
> hold back a bit in case there is any life out there that cares.

Contrary to you expectations, someone answered? =)

-Juha

_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
Kevin Bulgrien | 8 Aug 00:44 2009
Picon
Picon

Re: Bug 2789515: output-count broken since 1.11 server

> > After looking over the server code, it seems quite clear to me that
> > mwedel's suggestion to move it to the client is a good idea.
> 
> Do you have any idea how this affects the latency on longer network links and 
> when there are huge numbers of messages flowing? The output-count helped me a 
> lot sometimes.

I cannot say, but the SF tracker contains mwedel's comments to the effect that
the network bandwidth used by the messages is pitifully small compared to
other components of the traffic content.  While I am not sure that the comments
really take everything into consideration, I didn't really stop to think that
much about it either after I saw the number of conditions that were designed to
avoid use of the output buffers.  Still, there is that side that must admit that
when I did not have a DSL connection, though I was able to play crossfire, it
seems to me that I used to experience lag more often than I do now.  Some of it
was definitely not caused by output-count/sync issues, but I cannot say I could
be so definite about some of it actually being related to it.

Also, the output-sync/count facility appeared to only be expected to work under
some conditions.  I cannot say I fully followed the logic while looking at the
code because it was very convoluted and appeared to have been so quite some time
- notwithstanding it was broken the first time I looked at it.

A part of me would like to fix it... but probably mostly along the lines that it
is annoying when working code is broken because someone rewrites something, and,
because crossfire always given the impression of being network link intensive.
I may have given it a go if I felt more adept with svn.  Also, now that I have
DSL and it lets me be less concerned about speed, and as so few people seem to
play via internet (by the metaserver status), it did not occur to me to argue
long and loud against the suggestion to remove the code from the server.
(Continue reading)

Mark Wedel | 8 Aug 03:02 2009
Picon

Re: Bug 2789515: output-count broken since 1.11 server


  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 
(Continue reading)

Kevin Bulgrien | 19 Aug 03:59 2009
Picon
Picon

MSG_TYPEs vs in-Client configuration of routing and message folding.

The message types in the system are consecutive numbers from 1 to 20.  They are:

#define MSG_TYPE_BOOK          1
#define MSG_TYPE_CARD          2
#define MSG_TYPE_PAPER         3
#define MSG_TYPE_SIGN          4
#define MSG_TYPE_MONUMENT      5
#define MSG_TYPE_DIALOG        6   /* NPCs, magic mouths, and altars */
#define MSG_TYPE_MOTD          7
#define MSG_TYPE_ADMIN         8
#define MSG_TYPE_SHOP          9
#define MSG_TYPE_COMMAND       10  /* Responses to commands, eg, who */
#define MSG_TYPE_ATTRIBUTE     11  /* Changes to attributes (stats, */
                                   /* resistances, etc) */
#define MSG_TYPE_SKILL         12  /* Messages related to using skills */
#define MSG_TYPE_APPLY         13  /* Applying objects */
#define MSG_TYPE_ATTACK        14  /* Attack related messages */
#define MSG_TYPE_COMMUNICATION 15  /* Communication between players */
#define MSG_TYPE_SPELL         16  /* Spell related info */
#define MSG_TYPE_ITEM          17  /* Item related information */
#define MSG_TYPE_MISC          18  /* Messages that don't go anyplace else */
#define MSG_TYPE_VICTIM        19  /* Something bad is happening to player */
#define MSG_TYPE_CLIENT        20  /* Messages originated by the client */

I would like to consider changing the message types to bit values so that it
is easier to use masks to detect message types instead of having to do
sequential tests for individual values.  There are two immediate reasons for
this:

1) I want to the gtk-v2 client to easily allow in-client message routing by
(Continue reading)

Mark Wedel | 19 Aug 06:52 2009
Picon

Re: MSG_TYPEs vs in-Client configuration of routing and message folding.

Kevin Bulgrien wrote:
> The message types in the system are consecutive numbers from 1 to 20.  They are:
<snip>
> I would like to consider changing the message types to bit values so that it
> is easier to use masks to detect message types instead of having to do
> sequential tests for individual values.  There are two immediate reasons for
> this:

  First question I have would be can a message be of multiple types?  By having 
distinct (non bitmask values), a message can only be of one type.

  There probably isn't a wrong or right answer to that question, but that should 
be answered because it can affect future game decisions, and as you note below, 
by allow customizable routing one needs to now how they will work.  What you 
probably want to avoid is the case of assuming a message will only have a single 
bit set, and writing support for that, and then someone setting multiple bits on 
a message and then filing bugs saying support for that is broken.

> 
> 1) I want to the gtk-v2 client to easily allow in-client message routing by
>    type.  The short-term goal is to allow players to pick which messages go
>    to the so-called "critical messages" window.  In the longer term, an idea
>    was expressed that it might be nice to allow players to set up their own
>    number of text windows and route messages as they pleased.  In any case,
>    with the current message type numbering, one has to have statements like:
> 
>      if (type == MSG_TYPE_ATTRIBUTE
>      ||  type == MSG_TYPE_COMMUNICATION
>      ||  type == MSG_TYPE_DIALOG
>      ||  type == MSG_TYPE_VICTIM)
(Continue reading)

Kevin Bulgrien | 30 Aug 00:40 2009
Picon
Picon

GTK-V2 Message Control

SVN revision 12170 debuts the GTK-V2 Message Control system.  Earlier clients
had some of this functionality, but it could only be configured by changing
defines or code.  This revision implements a Client | Message Control menu
option and corresponding dialog.

The player can now select which message types pass through the client-side
output-count feature (duplicate message suppression) by simply marking a
checkbox alongside the message type.

Additionally, the player can configure which types go to which message panes
in the client - also by checking boxes.  The choice is not either/or, but
does allow messages to go to both (or none) if so desired.

The changes are made as soon as the Apply button is pressed.  There is no
need to restart the client.

This revision is not the final one though.  Presently the output-count is
fixed at 16 messages, and output-syn at 16 ticks (about 2 seconds).  These
options are slated for addition to the dialog.

Further, the dialog has a Save button, but it is disabled.  At some point
it is hoped that the player configured settings will be saveable and that
they will restore when the client is restarted.  This functionality is not
yet implemented.

The code is not quite finished, but this announcement is made in case anyone
wants to take a look.  The message duplicate suppression apparently has a
bit of a flaw.  Sometimes it actually causes duplicates... though it seems
it doesn't happen a lot so it is still very usable.  :-(  Anyway, that just
means it will not be long before there are updates.
(Continue reading)

Kevin Bulgrien | 30 Aug 06:55 2009
Picon
Picon

Re: GTK-V2 Message Control

> The message duplicate suppression apparently has a
> bit of a flaw.  Sometimes it actually causes duplicates... though it seems
> it doesn't happen a lot so it is still very usable.  :-(  Anyway, that just
> means it will not be long before there are updates.

r12172 fixes that bug.

Gmane