Packet Queueing And Castle Data Loading

Originally posted by theultramage
http://www.eathena.w...ker&showbug=287

I added a safeguard against send buffer overload (too many packets queued at once causing increased memory usage, etc), and this uncovered a very bad bug...

According to network traffic traces, this is what happens during startup...

1. The agit init script calls 'getcastledata(..., 0, ...).
getcastledata normally just returns a piece of information that's already loaded, but for some mysterious reason (probably stupidity), case 0 performs a charserver data load request instead - ONE F*CKING ATTRIBUTE AT A TIME

for(i=1;i<26;i++) // Initialize[AgitInit]
guild_castledataload(gc->castle_id,i);

As to why castle data loading isn't done automatically at initial charserver connect but instead the script engine has to request it, I'll leave that for future examination. The point is this packet spam.

2. After loading is done, the event provided with 'getcastledata' is executed for each callee (=> castle), which is...

OnRecvCastleN01:
RequestGuildInfo GetCastleData("nguild_alde",1);

which ends up with a 6-byte packet 0x3031 request (guild data lookup).

3. Charserver processes packet, and builds packet 0x3831, which contains a complete dump (!) of a guild object = 13kB, and shoves it into the send queue.
Now, this part is really dumb, because when a guild owns more than 1 castle, the data gets sent multiple times...

The result is that nCastles x 13K bytes gets shoved into the char->map pipeline at once (w/ redundancy). This, coupled with extra unsent stuff and increased castle count to 50 (or so I assume) causes a buildup of more than 1 MB of data, which the socket code will flag as overload and the connection will get killed.


In function WFIFOSET, there was once

if (s->wdata_size > (TCP_FRAME_LEN))
send_from_fifo(fd);

that actually forced the server to not buffer anything past 1 kilobyte. I nuked that part some time ago, and this is the result... I guess rethinking the strategy is in order...