[CF-Devel] Bad server bug again

[Michael Toennies]

Hi

Here is what i find out of the server bug.

First, marks change to the update/send part FORCES
the bug - now you can kill the connect when you collect a
pile of 40-50 items and stay up them.

The server can't then update the pile all the time and overload the
socket.

This will force this on server side:

LOGIN: Player named Darkmoon from ip 213.168.193.219
Socket on fd 6 has overrun internal buffer - marking as dead
make_path_tofile
/home/unitel/cf/crossfire/var/crossfire/players/Darkmoon/Darkmoon.pl...
LOGOUT: Player named Darkmoon from ip 213.168.193.219

On client side, i do this: Login, stay on a pile of items and wait.

I run in a old server version (xover.mud.at) through the magic shop
in scorn and collect the items. The magic wands has a animation, so they
force the server to update them.

This happens on old servers if you collect half of the shop items and drop
them
on one pile: Animation of wands force a small map update and a update item
command.
Update item will holds the wand animation, there is nothing in the stack as
5-6 wands and
all books and scrolls of the shop.

8522935 (index:2)::GetCommand:upditem -> len:9
8523251 (index:0)::GetCommand:map -> len:7
8523255 (index:0)::GetCommand:upditem -> len:9
8523257 (index:1)::GetCommand:upditem -> len:9
8523258 (index:2)::GetCommand:upditem -> len:9
8523259 (index:3)::GetCommand:stats -> len:3
8523260 (index:4)::GetCommand:map -> len:7
8523261 (index:5)::GetCommand:upditem -> len:9
8523539 (index:0)::GetCommand:map -> len:7
8523540 (index:1)::GetCommand:upditem -> len:9
8523541 (index:2)::GetCommand:upditem -> len:9
8523845 (index:0)::GetCommand:map -> len:7
8523847 (index:0)::GetCommand:upditem -> len:9
8523850 (index:1)::GetCommand:upditem -> len:9
8523851 (index:2)::GetCommand:upditem -> len:9
8523852 (index:3)::GetCommand:map -> len:7
8523855 (index:4)::GetCommand:upditem -> len:9
8523856 (index:5)::GetCommand:map -> len:11
8523857 (index:6)::GetCommand:upditem -> len:9

On the new one server code, look at this (same position, same kind of char,
same items):

7659080 (index:22)::GetCommand:delinv -> len:1
7659553 (index:0)::GetCommand:item1 -> len:3893
7659626 (index:0)::GetCommand:delinv -> len:1
7660138 (index:0)::GetCommand:item1 -> len:3893
7660139 (index:1)::GetCommand:delinv -> len:1
7660622 (index:0)::GetCommand:item1 -> len:3893
7660694 (index:0)::GetCommand:stats -> len:3
7660695 (index:1)::GetCommand:map -> len:10
7660696 (index:2)::GetCommand:delinv -> len:1
7661206 (index:0)::GetCommand:item1 -> len:3893
7661207 (index:1)::GetCommand:delinv -> len:1
7661693 (index:0)::GetCommand:item1 -> len:3893
7661766 (index:0)::GetCommand:delinv -> len:1
7662278 (index:0)::GetCommand:item1 -> len:3893
7662279 (index:1)::GetCommand:delinv -> len:1

The server sends the whole pile over and over!!! Thats because the upitem is
broken!
This is of course a serious bug.

But there is one good thing: it shows us what the real problem is:

Well, as i test, killing a SINGLE DRAGON will let drop him only some items -
But the data length of them in the item1 cmd is about 1.5k !!

So, imagine a monster, casting slows and paralyze on the player!
This will FORCE THE SERVER to update a pile under him again and again too!
And we got again a socket load of >10k per second because also a small pile
of around 10
to 15 items will have a size of 1.5 to 2.5k!!

I think, there is one more performance problem on server side too,
perhaps in control of sorting the items or so.

But the send amount of server->client is enough to invoke the problems:

For a single ISDN line a permanent download of >10k per second in a
real time enviroment not a trivial thing! Even permanent >2k are bad.And
even with faster
connections, these 'blocks' has a bad effect on your smooth game play.

We can't remove this problem by brute force like change update speed or so.
What we need is some more intelligent update procedure -which means:

- Sending a delinv and then a item1 command is senseless when the reason the
send it is, that
  a new item1 command comes in! Lets use a itemup1 cmd.
  Calling this instead of item1 cmd, will let make the delinv command on
client side
  automatically. You only need it, when you move or the pile get removed
without new items
  come in or whatever. This will also remove flicker to client.

- Below windows don't need animation update by server! Client can handle it,
  in fact they do it yet to normal inventory - so the changes should be done
in
  a few minutes coding!

- We don't need send the player 20 fire animation or any other mass spell
effect more than
  one time in the below window!!
  THIS WILL ALSO FORCE EVERY UPDATE AROUND 1000 bytes of DATA CASTED FROM A
2-3 DRAGONS!!
  THIS IS NOT A THING WE CAN IGNORE!
  Mark the mass spell effects with a spell effect flag! Thats trivial,
  we have a small and known amount of spell effect arches like fire, ice and
so on!
  Do a dirty flag list for every effect object. When send the arch, you OR
the spell effect
  flag(s) of the object. When the flag is set before, skip the face sending.
  We don't need to merge them or something, simple don't send them!
  Serious: You got around 5-10 updates of the below window very second. You
can't scroll
  through them in this speed, you can't even notice them if they are outside
of the visible
  window part, you can't read them or calc how much you see - WHY IN HELL
ARE THEY SEND TO
  PLAYER?

- Don't send bottom layer objects! This is a little complexer change, but
there is no need
  to send the player a grass tile! You can't apply it, you can see on map
what and where it is
  - it makes no sense to send this to player, so why we do it? Only send
them relevant or applyable
  item objects in below window! Mark them as "NOTSEND" in arches, and add a
DOSEND cmd to arches.
  SO, they don't get send by default but you can change this when the map
design need it!

- And the last thing is the one is the serioused one: We need a working
update below item stack.
  Means, its absolut idiotic to send the player the whole stack of the below
window again and again
  when he drops a item or manipulete the stack. Even adding or removing a
item from a chained list
  like what the below pile is, is a TRIVIAL thing.
  So, when we drop a item from our inventory adding it to below pile of 30
items, we should get a
  remitem cmd for our inventory and a additem cmd for our below windows. For
changing stats of
  a item we had the updateitem cmd.

Well, because we got this problems, let do this YET, before 1.0!
We have no choice! All other tricks are only hacks. No one can test all the
side
effect of it. I thing time will be same, and so its more than intellingent
to code
the working changes instead of some hacks.

If Mark, peter and i code together, we can handle this fast and has removed
the bug
and do some major improvement to CF in one action.

Michael