EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)
-   -   New Patch Changes! (https://www.eqemulator.org/forums/showthread.php?t=4683)

Joolz 01-08-2003 03:20 AM

New Patch Changes!
 
From the nice guys at ShowEQ:

Quote:

Some pretty major changes on test. Posting this mostly to help cut down on duplicated work. I havent worked through too much of it yet, but heres what I do know so far. Most all data is zlib compressed now, which is a nice bandwidth saver. The compression is basicly implimented so that multiple packets can be rolled together into a single compression block before being sent.

New opcode: 0x7642 - compressed data packet. Seems to have a 3-5 byte header then the zlib compressed data. If the 3rd byte is 0xff, its a 5 byte header, otherwise 3, it seems. Unsure of what the other stuff indicates so far. In the decompressed data, you've got 1 or more packets strung together, havent worked out exactly how this works, but you do still have the opcode and data for each packet.

Aside from all that, there appear to be some data structure changes, mostly in the form of 16 bit values being changed to 32 bits instead.

In short, lots of work to do
What does this mean for us? Well, we HAVE to implement the 16 bit to 32 bit transitions. That shouldn't take us too long.

As for the new opcode... well... these appear to be packets from the server. Also, the net code in its current form really doesn't need the overhead of zlib compression right now!

devn00b 01-08-2003 07:03 AM

Compressing every packet will/would be nice tho. would mean more bandwith for smaller server, for all those newly moving NPC's (since it has to send a npc update packet right?) or for other servers with lots of PC's moving about.

overall how much does compressing each packet save? my guess is that its not that much. but hey every little byte helps.

kathgar 01-08-2003 01:22 PM

But does the gain rom compression outweigh the expense of compressing is the problem. Hell, we may just get lucky and the client accepts the old way

Joolz 01-09-2003 07:46 AM

And... here we go!

Quote:

[19:10] <Joolz> Unknown opcode: 0x7642 size:129
[19:10] <Joolz> 0: 58 18 C4 78 5E CB 29 56 - 36 34 32 36 33 67 70 B3 | X..x^.)V64263gp.
[19:10] <Joolz> 16: CC CF 2C 88 4A CA 30 30 - 48 F6 09 29 B6 60 20 03 | ..,.J.00H..).` .
[19:10] <Joolz> 32: D8 01 F5 7C F9 2B CC 50 - C7 D0 C0 C0 F0 E6 6F BD | ...|.+.P......o.
[19:10] <Joolz> 48: 14 13 03 83 C7 4F 61 86 - 05 0A A2 0C 3F 7E 08 83 | .....Oa.....?~..
[19:10] <Joolz> 64: 4D CC 16 FD 5A EE CC C0 - 70 60 96 E0 D7 F2 F9 40 | M...Z...p`.....@
[19:10] <Joolz> 80: 8C 2C D6 F2 5B 98 E1 C3 - 2F 61 86 02 A0 19 AC 13 | .,..[.../a......
[19:10] <Joolz> 96: BE 97 AF B8 FA 0D 2C AF - 00 C4 95 4B 9E 97 83 68 | ......,....K...h
[19:10] <Joolz> 112: 90 FE DB E2 CF C1 66 80 - E4 0E 01 31 00 43 4F 2D | ......f....1.CO-
[19:10] <Joolz> 128: B8 | .
So, ladies.... compressed... HOW? Its bugging me now... I can't get zlib to do 'jack':

Client::Process()

Code:

                case 0x7642:{

                        cout << "Compressed packet data\n";

                        z_stream t;
                        APPLAYER *tmper;
                        tmper = new APPLAYER(0, 1024);

                        t.next_in = app->pBuffer;
                        t.avail_in = app->size;

                        t.next_out = tmper->pBuffer;
                        t.avail_out = tmper->size;
                        t.zalloc = (alloc_func)0;
                        t.zfree = (free_func)0;
                       
                        inflateInit(&t);
                        inflate(&t, Z_FINISH);

                        cout << t.total_out << '\n';

                        break;

always comes back with 0... arse!

kathgar 01-09-2003 08:50 AM

they might have compressed each seperatly .. or just fucked with the headers, or just not used zlib..

Joolz 01-09-2003 09:00 AM

They did use zlib... If you decompress the above packet, you get:
Quote:

0: 6C 73 23 31 32 33 36 37 - 00 72 4E 54 65 62 75 39 | ls#12367.rNTebu9
16: 6A 74 4B 65 6D 4A 48 53 - 00 00 00 00 00 00 00 00 | jtKemJHS........
32: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
48: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 | ................
64: 00 00 00 00 00 00 00 00 - 00 00 00 00 3E 00 00 00 | ............>...
80: F4 FD 13 00 7E 00 80 00 - 00 EC FD 7F 1A 02 00 00 | ....~...........
96: 48 F9 13 00 A0 20 15 00 - F8 F8 13 00 00 00 00 00 | H.... ..........
112: 6B 15 F5 77 43 00 00 C0 - 9A 11 F5 77 9F 11 F5 77 | k..wC......w...w
128: 00 00 00 00 6B 15 F5 77 - 43 00 00 C0 84 FB 13 00 | ....k..wC.......
144: F0 FA 13 00 70 FD 13 00 - 05 90 F7 77 A8 D5 F6 77 | ....p......w...w
160: 00 00 00 00 20 00 00 00 - 79 A4 E7 77 20 00 00 00 | .... ...y..w ...
176: 6B 15 F5 77 DB 17 E7 77 - 43 00 00 C0 00 00 00 00 | k..w...wC.......
192: C2 00 00 00 | ....
So... what does that mean? There's no recognisable opcodes... (this is the first packet sent by the client to the server)

Joolz 01-09-2003 09:09 PM

As correctly pointed out, its a login packet... but, where is the opcode header etc? Good question!

Joolz 01-09-2003 09:19 PM

Reality check! Done it.... I now have logging in working on the new EQEMU... I will check changes in tonight when I get home from work.

Shame no one really helped me... But at least I got it done.

Shawn319 01-10-2003 02:04 AM

Quote:

Originally Posted by Joolz
Reality check! Done it.... I now have logging in working on the new EQEMU... I will check changes in tonight when I get home from work.

Shame no one really helped me... But at least I got it done.


You work too fast lol!!! Theres no time for anyone to help you :)

01-10-2003 02:08 AM

do you suspect a new emu for these changes or perhaps just a patch?

_____
EL/FA

Joolz 01-10-2003 06:01 AM

I'm porting the structure changes now... This will be a new emulator.. + when the new emulator comes out... the old version of EQ will NOT NOT NOT work with it.

mByte 01-10-2003 11:09 AM

Quote:

Originally Posted by Joolz
I'm porting the structure changes now... This will be a new emulator.. + when the new emulator comes out... the old version of EQ will NOT NOT NOT work with it.

All previous work is back to stage 1?

just_add_water 01-10-2003 12:48 PM

.. is it that hard to understand? i mean gezz

Quote:

This will be a new emulator.. + when the new emulator comes out... the old version of EQ will NOT NOT NOT work with it.
That mean your gonna need to patch to play on 0.4.2 servers (when 0.4.2 comes out and ONLY THEN SO *DON'T* PATCH RIGHT NOW)

Joolz 01-10-2003 07:04 PM

I did think that what I said was simple to understand. Although do understand that we do need to start the structs from scratch :(

killspree 01-11-2003 02:48 PM

I've had the opprotunity to test out the new compression on EQlive, and I have to say it's simply amazing. It looks like it's very worth it, as the connection lag I had with ~80 people in an area while a raid was going on, was about the same as the lag I'd have with about 30 people prior to this patch.


All times are GMT -4. The time now is 11:18 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.