|
Well We all know that there is communication between server and client. Ive always been checking out the client from since I started RSPS.
At 508 I noticed that the client only read 5000 bytes from the server per flush.
Eventually, I think around 560+ they increased the size to 7500 bytes. This means if you're flush is is ever greater than 7500 bytes, the remaining bytes will be lost (causing in most cases packet errors)
The reason I bring this up is I hear all the time "I spawned 2000 players at once". This is pure false. It requires way more than 5000 or 7500 bytes to spawn more than 2000 players at once. If u notice on runescape Player's are added in segments of updates. Meaning that 500 will be added in one update (if the payload permits) and some more in the next, and so on and so on. Bottom line is The number of players u see per 600ms depends on the number of bytes the server is sending.
Ive always wondered why runescape didn't use like 40kb or 100kb per update, but then again bytes are read from the server by the client every 30ms (even though the server only sends packets every 600ms).
nice hotyute i learned something today
In netty this is pretty easy to do. If the outgoing buffer is bigger than the maximum size the client reads every 30ms, take the first amount of bytes, send them and fire a new outbound event with the remaining buffer until the buffer is completely send.
I think the reason is networking overhead. It's better to spread traffic than having all traffic at once.
The only client that I've deobfuscated and refactored a bit that has an incoming buffer of size 7,500 is 616. The rest (613, 607, 604, 591, 578, etc.) only use a buffer of size 5,000. This definitely didn't change around revision 560.
I'm pretty sure it was still 5000 at 562. Anyways, yeh adding players has a max defined aswell iirc
Thanks Sam, already knew about the player adding stuff, but i didn't know exactly how big the buffer size was.
Ye this was disconnecting me with large amounts of players (tryed adding a max of adding 8 new players per cycle because appearance is a pretty big chunk, but just the spamming alone from 250 players (2k or 250 doesn't really make a diff..) could dc me sometimes sizes of 5.5-6.5k iirc) i changed the incomming buffer to 10k a while ago for testing, and i am yet to dc with a packet error
So does the client parse packets every 30ms? Meaning sending data bit by bit, as Maxi suggested, would work?
Uh that 30ms parsing is for other packets aka frames, the client still needs to read the updating block as one packet
the read method will throw an out of bounds exception when the length (packetsize included in the packet) > buffer.length and will block untill the whole packet is readCode:while (len > 0) { int read = anInputStream1127.read(buffer, startOffset, len); if (read <= 0) throw new EOFException(); len -= read; startOffset += read; }
Just make your player update not send all renders at once as it the part of update that uses more data(I limited 2500bytes to it here =p)... Also use cached render appearences too it helps alot and make a limit of adding players per loop (250 here =P). I made my 562 client load up to 1k players without editing max packet size and works =).
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |