PacketID: 27715

[Y u k i]

18 00 F2 03 F9 FD A3 19 63 42 0F 00 00 00 00 00 00 00 00 00 00 00 72 00 54 51 43 6C 69 65 6E 74 18 00 F2 03 FA FD A3 19 63 42 0F 00 00 00 00 00 00 00 00 00 00 00 4B 00

òáA¨cBrTQClientòáA¨cBK

PacketID: 27715
Size: 56

Offset 8 - Character UID
Offset 34 - 1010 (MsgAction?)


Packet does NOT change. Always sending the exact same bytes on LOGIN.
Echoing back to the client results in a DC not in a client close.

Anyone knows anything about it?

Oh yeah, packets can be sent in chunks... thats what I get for not implementing a split packet handler..

TCP/IP y u do this to me?

[Korvacs]

Looks like its 2 packets to me that haven't been split correctly, given the length is 24 for both packets. Oh and the type is 1010 in both cases.

[Y u k i]

Originally Posted by Korvacs

Looks like its 2 packets to me that haven't been split correctly, given the length is 24 for both packets. Oh and the type is 1010 in both cases.

Yeah, just figured that out myself haha... wow.. embarassing. Thanks tho jack!

[jackpotsvr]

Sad, no undiscovered packet was found that day ;p

[Korvacs]

Oh and its TCP/IP.

[-impulse-]

Yuki, when implementing a packet splitter you might want to enqueue everything you get and then split from the top and not directly what you get from the receive function. On localhost it won't make a difference but on the Internet it will.

[Korvacs]

Oh and a packet ID of 27715? You realise thats 'Cl' from 'TQClient' right? How on earth did you pull the packet ID from that part of the packet?

[CptSky]

Packet buffering is not only part of TCP/IP. Anyway, you need a packet splitter, but also you need to handle packet fragmentation, which is something else.

[Y u k i]

Originally Posted by Korvacs

Oh and a packet ID of 27715? You realise thats 'Cl' from 'TQClient' right? How on earth did you pull the packet ID from that part of the packet?

Well I got a receive loop and it always reads the 2nd offset as a Int16.

for (int Counter = 0; Counter < Recv.Length; Counter += Size)
                    {
                        Size = BitConverter.ToUInt16(Recv, 0);
                        ushort Type = BitConverter.ToUInt16(Recv, 2);
                        if (Size != Recv.Length)
                        {
                            byte[] Chunk = new byte[Size];
                            Buffer.BlockCopy(Recv, Counter, Chunk, 0, Size);

                            ThreadPool.QueueUserWorkItem(O =>
                            {
                                PacketHandler.HandlePacket(Client, Type, Chunk);
                            });
                        }

Well, I guess we all see why it doesnt work dont we?

[SteveRambo]

Originally Posted by Y u k i

for (int Counter = 0; Counter < Recv.Length; Counter += Size)
                    {
                        Size = BitConverter.ToUInt16(Recv, 0);
                        ushort Type = BitConverter.ToUInt16(Recv, 2);
                        if (Size != Recv.Length)
                        {
                            byte[] Chunk = new byte[Size];
                            Buffer.BlockCopy(Recv, Counter, Chunk, 0, Size);

                            ThreadPool.QueueUserWorkItem(O =>
                            {
                                PacketHandler.HandlePacket(Client, Type, Chunk);
                            });
                        }

Well, I guess we all see why it doesnt work dont we?

You do realize it's a terrible idea to use more than a single thread for packet processing, right? I'm talking about your usage of the ThreadPool class.

[Spirited]

Originally Posted by SteveRambo

You do realize it's a terrible idea to use more than a single thread for packet processing, right? I'm talking about your usage of the ThreadPool class.

That's not good advice either though. Multithreading is definitely a good idea for packet processing, but using a ThreadPool from C# is not. Managing your own worker threads and the number of threads processing requests at one given time is optimal. A single thread processing all requests for a server... bad idea.

Edit: Also, I have a packet splitter / fragment handler for my server that should be more or less public on my blog. I think I made modifications to it in my project since posting it on my blog, but it should work as is. Step through the design before implementing it.

[SteveRambo]

Originally Posted by Spirited

That's not good advice either though. Multithreading is definitely a good idea for packet processing, but using a ThreadPool from C# is not. Managing your own worker threads and the number of threads processing requests at one given time is optimal. A single thread processing all requests for a server... bad idea.

Edit: Also, I have a packet splitter / fragment handler for my server that should be more or less public on my blog. I think I made modifications to it, but it should work as is.

... you might as well just use UDP then, if you don't care in what order your packets are processed

[Spirited]

Originally Posted by SteveRambo

... you might as well just use UDP then, if you don't care in what order your packets are processed

TCP sends packets in order, thus the server receives packets in order. For things that need to be processed one at a time, use queues. Processing all packets on one thread is idiotic - it's just going to bottleneck at the packet handler.

[SteveRambo]

Originally Posted by Spirited

TCP sends packets in order, thus the server receives packets in order.

Player jumps from position 300, 300 to 300, 310 and sends packet A to the server with this information.
Player jumps from position 300, 310 to 300, 320 and sends packet B to the server with this information.

The server receives packet A and B in the correct order, because the server uses TCP.

The server uses a thread pool to process packets, so both packet A and B are submitted to the thread pool for processing.

The server uses thread A for processing packet A and thread B for processing packet B.

While processing packet A in thread A, the operating system suddenly decides to stop thread A before it's done processing and gives thread B time to run.

Thread B happens to complete the processing of packet B and now the operating system gives time for thread A to continue again.

What happens then? The client is going to get disconnected because the server processed the packets in the wrong order: it thinks that the player jumped from 300, 300 to 300, 320 (distance = 20 ==> disconnect).

[KraHen]

Originally Posted by SteveRambo

Player jumps from position 300, 300 to 300, 310 and sends packet A to the server with this information.
Player jumps from position 300, 310 to 300, 320 and sends packet B to the server with this information.

The server receives packet A and B in the correct order, because the server uses TCP.

The server uses a thread pool to process packets, so both packet A and B are submitted to the thread pool for processing.

The server uses thread A for processing packet A and thread B for processing packet B.

While processing packet A in thread A, the operating system suddenly decides to stop thread A before it's done processing and gives thread B time to run.

Thread B happens to complete the processing of packet B and now the operating system gives time for thread A to continue again.

What happens then? The client is going to get disconnected because the server processed the packets in the wrong order: it thinks that the player jumped from 300, 300 to 300, 320 (distance = 20 ==> disconnect).

This. For the last week I`ve been rewriting the way we handled packets for a rather large project at my job for exactly the same reason.