0x42?

[NiNe]

What is 0x42?

[DeTaiLs]

0x42 - SID_CDKEY3 D2 beta?  Not sure though.

[NiNe]

Hurem, I dont think its for D2, I think its for W2BN, But im not sure either

[Blaze]

Was it sent to you? and at what point? Packet log?

[NiNe]

Yes it was sent to me, and it was apon enter chat, and packet log is:

Code Select Expand

Unidentified Packet: 0x42
4E 42 32 57 20 30 20 30 20 38 36 20 30 20 30 20     NB2W 0 0 86 0 0
30 20 30 20 30 20 4E 42 32 57 00 FF 0F 3B 00 01     0 0 0 NB2W   ; 
00 00 00 00 00 00 00 6E 00 00 00 00 00 00 00 0D            n       
F0 AD BA 0D F0 AD BA 4E 69 4E 65 00 4E 42 32 57            NiNe NB2W
20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30      0 0 0 0 0 0 0 0
20 4E 42 32 57 00 FF 0F 45 00 01 00 00 00 00 00      NB2W   E       
00 00 7D 00 00 00 00 00 00 00 0D F0 AD BA 0D F0       }             
AD BA 5E 5F 2D 69 7C 4C 65 24 27 7C 27 2D 5F 5E       ^_-i|Le$'|'-_^
00 4E 42 32 57 20 30 20 30 20 30 20 30 20 30 20      NB2W 0 0 0 0 0
30 20 30 20 30 20 4E 42 32 57 00                    0 0 0 NB2W

[Blaze]

-.- Thats a 0x0F packet...

[NiNe]

I dont think so =\

[Blaze]

4E 42 32 57 20 30 20 30 20 38 36 20 30 20 30 20 NB2W 0 0 86 0 0
30 20 30 20 30 20 4E 42 32 57 00 FF 0F 3B 00 01 0 0 0 NB2W ;
00 00 00 00 00 00 00 6E 00 00 00 00 00 00 00 0D n
F0 AD BA 0D F0 AD BA 4E 69 4E 65 00 4E 42 32 57 NiNe NB2W
20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 0 0 0 0 0 0 0 0
20 4E 42 32 57 00 FF 0F 45 00 01 00 00 00 00 00 NB2W E
00 00 7D 00 00 00 00 00 00 00 0D F0 AD BA 0D F0 }
AD BA 5E 5F 2D 69 7C 4C 65 24 27 7C 27 2D 5F 5E ^_-i|Le$'|'-_^
00 4E 42 32 57 20 30 20 30 20 30 20 30 20 30 20 NB2W 0 0 0 0 0
30 20 30 20 30 20 4E 42 32 57 00 0 0 0 NB2W

[NiNe]

Aww i see now, its cluttered stupid me

[Blaze]

Bnet usally sends 0x0F User in Channel in one big clump.

[Joe[x86]]

Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.

Now, I'm asuming that we have a packet, or a series of them, in strBNCS. I know I'm likely to be the only one to use that name, so change it accordingly.

Code Select Expand

Public Sub PrepareParse(strBNCS as String)
    While Len(strBNCS) > 4
        ParseBNCS Mid(strBNCS, 1, GetWORD(Mid(strBNCS, 3, 2)))
        strBNCS = Mid(strBNLS, GetWORD(Mid(strBNCS, 3, 2)) + 1)
    Wend
End Sub
Right?

[Hdx]

Try using it in _DataArrival, Then have it parse out then length, if the lengtih of the buffer > LengthOfPacket then parse it, else wait till next dataarival.

Code Select Expand


Static strBuffer As String
Dim strTemp As String, lngLen As Long
With Config(Index)
wsBNET.GetData strTemp, vbString
strBuffer = strBuffer & strTemp
        While Len(strBuffer) > 4
            lngLen = GetWORD(Mid(strBuffer, 3, 2))
            If Len(strBuffer) < lngLen Then Exit Sub
            Call ParseBNCS(Left(strBuffer, lngLen))
            strBuffer = Mid(strBuffer, lngLen + 1)
        Wend
as such, works perfectly for me.

Ah, wonderful. Another reason that packets suck and CSB owns.

No jsut anoyher reason you need to fix your coding, CSB does the egzact same thing, it parses out each packet even if there jumbled together, Self-Parsed will forever be greater then CSB.
~-~(HDX)~-~

[tA-Kane]

Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.

Packets rock, CSB sucks. I hate text-based protocols. Packets are so much more definite, IMO. For one, it's easier to know whether or not you've received a whole "message" when the underlying protocol specifies the length of the message. Most text-based protocols do specify a maximum length of messages, but without a message length specifier, there is no telling when you might receive a message longer than the specified length. For example, IRC specifies that the end of a message is crlf, and that a message can not be longer than 512 bytes (including the crlf, so a total of 510 bytes for the message). So what do you do if you receive 512 bytes and still have not received crlf? You close the connection and go "wtf GAY PROTOCOL!!!"

[dxoigmn]

Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.

Packets rock, CSB sucks. I hate text-based protocols. Packets are so much more definite, IMO. For one, it's easier to know whether or not you've received a whole "message" when the underlying protocol specifies the length of the message. Most text-based protocols do specify a maximum length of messages, but without a message length specifier, there is no telling when you might receive a message longer than the specified length. For example, IRC specifies that the end of a message is crlf, and that a message can not be longer than 512 bytes (including the crlf, so a total of 510 bytes for the message). So what do you do if you receive 512 bytes and still have not received crlf? You close the connection and go "wtf GAY PROTOCOL!!!"

And?  What do you do if you receive a packet with a specified length of 0xffff but never actually receive all those bytes?  You close the connection and go "wtf GAY PROTOCOL!!!"

One of the things binary protocols do better is not wasting space as a text protocol does.   However, with text protocols it's readable.  There are certain tradeoffs.

[MyndFyre]

Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.

You do realize that CSB just hides the packet data from you, the user of CSB, right?  It's called "information hiding," a very effective and efficient programming practice.  Unfortunately, CSB does *not* allows you as much flexibility as you might like, such as a priority-based event caller and the like.  So when information is hidden and you work with only an interface, the way in which the interface is exposed defines how much you can do with it.