problem at packet splitting

09/17/2012 15:55 go for it#1
im having problem with getting wrong packets and everyone told me it's because wrong packets splitting but it doesn't make sense for me because
Code:
Packet Nr 8319. Server -> Client, Length : 92, PacketType: 1008
54 00 F0 03 46 BB 77 02 F3 4A 02 00 BB 11 F7 11      ;T ðF»wóJ »÷
03 00 06 00 00 00 00 00 0D 0D 00 00 00 00 00 00      ;      

      
00 05 00 00 00 00 00 00 00 00 00 00 00 00 01 00      ;              
09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;	               
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
00 00 00 00 54 51 53 65 72 76 65 72                  ;    TQServer


Packet Nr 8320. Server -> Client, Length : 8456, PacketType: 17959
00 21 27 46 00 10 00 01 00 00 00 05 00 00 00 51      ; !'F        Q
6A D2 6E 04 00 00 00 00 00 00 00 00 00 00 00 00      ;jÒn            
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
00 00 00 54 51 53 65 72 76 65 72 34 00 21 27 46      ;   TQServer4 !'F
00 10 00 01 00 00 00 05 00 00 00 9F 33 44 70 04      ;        Ÿ3Dp
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
at the above packets , im splitting whenever i find the tq server/client seal , it did split at the seal and on the next packet length is x2100 aka 8448d
which to why it doesn't split on the next tqserver seal x7265767265535154

so even if i removed the length check which should not split until the length complete it will be like
Code:
Packet Nr 8320. Server -> Client, Length : 8456, PacketType: 17959
00 21 27 46 00 10 00 01 00 00 00 05 00 00 00 51      ; !'F        Q
6A D2 6E 04 00 00 00 00 00 00 00 00 00 00 00 00      ;jÒn            
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
00 00 00 54 51 53 65 72 76 65 72
which still wrong packet , length is still 8448 and type still 17959 which will still disconnect me
so should i just split on the seal no matter the length and block server -> client packets which got higher length than normal or unknown types ? will that stop disconnecting me ?

Edit :
at the end of the previous long packet
Code:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ;                
54 51 53 65 72 76 65 72                              ;TQServer


Packet Nr 8321. Server -> Client, Length : 8, PacketType: 25939
54 51 53 65 72 76 65 72                              ;TQServer


Packet Nr 8322. Server -> Client, Length : 8, PacketType: 25939
54 51 53 65 72 76 65 72                              ;TQServer


Packet Nr 8323. Server -> Client, Length : 8, PacketType: 25939
54 51 53 65 72 76 65 72
it does split on that length also on the seal and the next packet only contain the seal
so assume ill merge the end of that long packet and next packet that only contain the seals
Code:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 54 51 53 65 72 76 65 72 54 51 53 65 72 76 65 72 54 51 53 65 72 76 65 72
so in both case if i split on the length or even seal ill get the same result on the packet that only contain the seal which disconnect me , even when i block it from reaching the client , it still disconnect me
09/17/2012 16:03 I don't have a username#2
How do you split them?
09/17/2012 16:15 go for it#3
i did try the private server splitting method also pro4never one (proxy based)
so here is the one im using right now which is pro4never one (i doubt it's the server who send wrong packets)

split server

split client

here is how i try to block them
Code:
                        if (BitConverter.ToInt16(data, 0) < 1024 && BitConverter.ToInt16(data,0) > 8)
09/17/2012 16:35 I don't have a username#4
That's some rubbish code o.o
Why not just split like this?
Code:
        public static unsafe void Handle(DataPacket Packet)
        {
            if (Packet.Size == Packet.Buffer.Length)
            {
                Process(Packet);
                return;
            }
            int Counter = 0;
            while (Counter < Packet.Buffer.Length)
            {
                ushort Size = Packet.ReadUInt16(Counter);
                if (Size < Packet.Buffer.Length)
                {
                    byte[] qPacket = new byte[Size];
                    System.Buffer.BlockCopy(Packet.Buffer, Counter, qPacket, 0, Size);
                    Process(qPacket);
                }
                else if (Size != Packet.Buffer.Length)
                {
                    // disconnect ??
                    break;
                }

                Counter += Size;
                System.Threading.Thread.Sleep(1);
            }
        }
09/17/2012 16:58 go for it#5
ill check this out , but both are kinda the same
anyway thanks for helping mate
09/17/2012 21:10 InfamousNoone#6
If you've written your network class correctly in the most scalable manor, you shouldn't need to split packets at all.
09/18/2012 01:09 go for it#7
yup i think if i got a decent network class i could 've implement an advanced way to handle the packets much better than that
but sadly im not hybrid and sadly im still learning
but hey
on scale of 0 to 10 tell me how is that related to the current problem im having ?
lmao definitely
09/18/2012 01:20 pro4never#8
He is correct.

This can be handled in much more efficient ways right within the network class EG: Only handle the receive buffer once a full packet is receive and split based on the read length right inside the socket events.. With all the issues you're having, I would strongly recommend taking that route.

My original proxy was based on very poor code that I had simply re-worked to fit my needs and proxy paradise was simply an hour or two worth of re-hashed coding to make a workable and reasonably readable example.

If you're experiencing this level of issues with it then I'd strongly recommend taking the time to make something more solid, scalable and efficient.
09/18/2012 02:31 go for it#9
if i was able to write a decent "network class to handle received buffers which split and handle stuff" i wasn't to use your base , right :) ?
im learning from the source , im trying to add/remove some stuff , experience how to handle packets and im really pleased with the information im getting that ofc will help me when i write my own base
but when i experience a problem i keep searching and sometimes spending days trying on my own but when i lose hope i come here to ask about it , so when i figure out the solution i learn from it
what he said was completely right , but not the best option i've right now and wasn't even a solution as i can't write my own base yet

thanks anyway and i don't mean to say harsh words but his reply was pretty funny to me
09/18/2012 07:07 InfamousNoone#10
Quote:
Originally Posted by go for it View Post
yup i think if i got a decent network class i could 've implement an advanced way to handle the packets much better than that
but sadly im not hybrid and sadly im still learning
but hey
on scale of 0 to 10 tell me how is that related to the current problem im having ?
lmao definitely
10, approach your problem in a different manor so you don't need to split packets

receive 2 bytes,
decrypt them
convert to int16 -> consider this value to be nSize
if nSize is below 0 or greater than 2^12 drop the connection, if not cont.
receive nSize - 2 bytes
decrypt them
append onto the 2 bytes previously received
receive 8 bytes
decrypt them
verify they're "TQClient" or "TQServer"
queue packet to be processed since it's passed validity test

repeat seq.
09/18/2012 07:15 shadowman123#11
Hmm I got a question How do i know that the code i write is efficient or not ?
09/18/2012 14:34 go for it#12
Quote:
10, approach your problem in a different manor so you don't need to split packets

receive 2 bytes,
decrypt them
convert to int16 -> consider this value to be nSize
if nSize is below 0 or greater than 2^12 drop the connection, if not cont.
receive nSize - 2 bytes
decrypt them
append onto the 2 bytes previously received
receive 8 bytes
decrypt them
verify they're "TQClient" or "TQServer"
queue packet to be processed since it's passed validity test

repeat seq.
mate the way you just mentioned is actually perfect , but the point you can't understand is that im still learning , im writing my own base and ill do my best to implement this sequence on receiving , thanks for helping me out

Quote:
Originally Posted by shadowman123 View Post
Hmm I got a question How do i know that the code i write is efficient or not ?
when you don't get weird types and lengths , the way i were using does last for maybe 1-10 mins till it disconnect due to wrong packets (merge/split in wrong way)
but the way hybrid just said is the best in my point of view
09/18/2012 14:45 Korvacs#13
Quote:
Originally Posted by InfamousNoone View Post
10, approach your problem in a different manor so you don't need to split packets

receive 2 bytes,
decrypt them
convert to int16 -> consider this value to be nSize
if nSize is below 0 or greater than 2^12 drop the connection, if not cont.
receive nSize - 2 bytes
decrypt them
append onto the 2 bytes previously received
receive 8 bytes
decrypt them
verify they're "TQClient" or "TQServer"
queue packet to be processed since it's passed validity test

repeat seq.
Receive 4 bytes rather than 2 and after decryption check that the packet type is valid for the size your receiving.

Then proceed to receive the body.
09/18/2012 17:47 pro4never#14
Quote:
Originally Posted by shadowman123 View Post
Hmm I got a question How do i know that the code i write is efficient or not ?
When you accomplish your task successfully using the least amount of memory balanced versus the least amount of processing power.

Basically you say "This function works, it does what I want it to do but could I write it in another way which would use less processor instructions or free up more memory?"

Having a good knowledge of how things CAN be written goes a long way towards this self criticism so you can re-vamp your code to make it more efficient.

For example.... I've been working on some 3d graphics programming. I was able to generate and draw cubes just fine using 6 vertexes per face (36 verts per cube). I then said "this is dumb. Each face only really has 4 points" so I re-wrote the code so that it used vertexes and indices to make each face only use 4 vertexes.


Then I wrote it so I could generate LOTS of boxes. I then said "this is stupid, most of these faces aren't even visible!" so I wrote an algorithm to determine what faces where relevant and ONLY generate visible faces. As a bonus I wrote it so this code is only executed ONCE and the final results are stored so that they can be drawn whenever needed without re generating the 'terrain'.

Basically taking your working code and seeing how you could make it put less strain on your system is how you make sure your code is efficient. I'm sure there's ways I can further improve my own little project but I'm currently as efficient as I'm aware I can get given my current program needs. As I continue writing though, I need to be aware of my improvements and take the time to go back and rework existing code so it works in a more efficient manner.



LONG EXPLANATION IS LONG!
09/18/2012 21:55 go for it#15
Quote:
LONG EXPLANATION IS LONG!
epic explanation is epic :D
Quote:
Receive 4 bytes rather than 2 and after decryption check that the packet type is valid for the size your receiving.

Then proceed to receive the body.
i find that even better