[crossfire] channels

[Brendan Lally]

On Thursday 28 Apr 2005 07:43, Mark Wedel wrote:

>
     
      >>  Note that these preferences are also stored client side.  So this makes
     
     >
     
      >>
     
     >
     
      >>> dynamic channels harder to handle - channel 25 may change its meaning
     
     >
     
      >>> run to run, or perhaps even server to server.  I don't have a good
     
     >
     
      >>> solution for that one.
     
     >
     
      >
     
     >
     
      > which was why I was doing it server side.
     
     >
     
     
     >
     
        Which I'm not sure is the right approach.  IMO, client appearance issues
     
     >
     
      should be stored with the client, not on the server.  One way to think
     
     >
     
      about this is that if I do set prferences for those 30 channels, I really
     
     >
     
      don't want to have to do that again for each player I may start, and/or
     
     >
     
      each server I play on.
     
     
this is true, however certainly on a server-by-server basis, there may well be 
reason to ignore different channels, so simply saying that one solution from 
the client is correct for all servers may not be the right thing to do 
either.

having said that, I am now inclined to leave the default appearance as it is, 
and use Tchize's new call, since that will allow me to send the information 
that is needed, and provides a good solution to the issue.

3 major channel types - system server and personal, each will be a type under 
his approach, each will have a subtype corresponding to channel number. Since 
the number of server channels will be fixed, the numbers will be stored 
client side and interpreted there (less bandwidth, since there can be a /lot/ 
of messages). since the messages on the system channels will all be fixed 
anyway, formatting can be done based on the number sent (channel foo is red, 
channel bar is blue)

For the others, the channel name is sent as the first part of the message, the 
name of the person as the second, and the message as the rest. Chat channels 
are less noisy than the 'nty-one times you search the area style messages 
anyway' and the increase in data sent is only a handful of bytes anyway.

what the client should do with that I'm not to bothered, if it wants tabs, 
then assign tabs based on the name (since the numbers of the dynamic channels 
might alter, but the system ones would be fixed (with maybe some added, but 
not taken away), it can do as it chooses with channels, I'm not too bothered. 
If it has an easy way that as an abstract thing I could see how it might maybe 
draw messages from different people in different colours or have /ignore (for 
players) done client side really easily.

in this case then, the colours that are sent are really only for legacy client 
support, so that maybe how many there are is less important, and the only 
issue server side is whether to handle the channel or not.

>
     
        The general design philosphy is that anything that can be done on the
     
     >
     
      client should be done on teh client.  Only stuff that can't be done on the
     
     >
     
      client securely should be done on the server (securely in this context
     
     >
     
      means not giving the client info it shouldn't have).  there are several
     
     >
     
      reasons behind this philosphy, but mostly it boils down to trying to keep
     
     >
     
      the server code as simple as possible (reduces CPU usage, less likely to be
     
     >
     
      exploits, etc).
     
     
At the moment what I do is store the channels that are not on their default 
setting in the player file, then when someone reconnects, it tries to alter 
all channels that are listed. The ones that are non-default cause a message 
to be printed. (actually thinking about it that is the wrong way round, I 
should make it list the channels that no longer exist, this way the player 
will know when a channel they listen too is no longer available). 

However, wrt the system channels, thinking that at some point there might be 
30+ people on a server (metalforge gets close at times), the traffic 
requirements could get quite high on the global channels, COMM_KILLS 
especially. if 20 of them were killing monsters at a rate of 2 a second, then 
there would be 40 messages sent a second, each of these would be about 
50bytes, that is  2KB a second. That isn't a whole lot, except that now modem 
users are unable to play the game at anything like a sane speed. for the 
server, you have 100-200KB a second being sent, which is a fair amount, and 
something that it would be nice to reduce/remove.

In addition to this, unless server subscription is server side, there is no 
way to enforce kicking (which I have already implemented) or banning (which I 
have mostly implemented), I'm not sure yet whether to have invite only 
channels, that is another instance where server side knowledge of the 
channels a player is subscribed to is needed. In that case then, since there 
have to be some channels monitored server side, it is probably best to do 
them all that way.

In fact the only disadvantage with this approach that I can see is that it 
requires me to change all the new_draw_info commands again, but I should be 
able to do that next wednesday. In the meantime, I have some other 
commitments that are going to try and keep me away from cf over the rest of 
this week/weekend, so I'll wait until Tchize's patch is in and then try and 
fit what I have done around that.