pineapple... this is ridiclious

So store those game settings (chat/invites) server side, and when the player opens the menu, retrieve them from the server, when the player accepts it, send them back. Stop it at the server if the player's options say so, don't even forward it.


Or just increment a little "whispers sent" / "invites sent" every time they do it, and if someone's pushing in more than, say... 100 in a minute. Give them a 1 hour tempban. Don't rely on the client's flood control to prevent people from flooding; if the server is being flooded, give them a short ban.

Like I explained before:

 Spoiler

http://www.southperry.net/forums/showpos...stcount=21

Q4: What do you mean by database reading?
A: Lets create our own D/C hack solution. Imagine we put at Nexon database an new field called: "Accept_Whispers". So next time someone send you a message it gona be like that:
1- client send a private message to Nexon Server
2- Nexon server check in the "Accept_Whispers" field if the desired person is currently accepting whispers;
2.1- If Yes: show;
2.2 If No: tell the sender: desired person not accepting;

Now Nexon Server aren't knocking our client for a answer. And its gona protect us from massive questioning and, maybe, preventing the d/c or lag. But this solution will create massive amounts of database reading and memory allocation to temporary store the messaging waiting for its destiny and cpu usage. Why? Image thousands of clients asking Nexon Servers about person "game options" several times.

Server side database solution is not good, it will create massive amounts of read/write and memory and CPU usage at game servers, even if you put some protection like: max requests/seconds, still create lots of CPU usage and memory allocation, resources already allocated deal w/ currently game problems. In other words, more stuff at database, more physical space to allocate, more disk usage, more checkups at server code, raising the complexity, it can drop server performance and affect game play.

Taking care of this problem at network/routers side is more complex, but better : blocking those harm packets before reach server is the best solution for both sides (client-server) (in my opinion).