Author | Message | Time |
---|---|---|
NiNe | What is 0x42? | January 30, 2005, 10:38 PM |
Twix | 0x42 - SID_CDKEY3 D2 beta? Not sure though. | January 30, 2005, 10:49 PM |
NiNe | Hurem, I dont think its for D2, I think its for W2BN, But im not sure either | January 31, 2005, 12:37 AM |
KkBlazekK | Was it sent to you? and at what point? Packet log? | January 31, 2005, 12:39 AM |
NiNe | Yes it was sent to me, and it was apon enter chat, and packet log is: [code]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 [/code] | January 31, 2005, 12:45 AM |
KkBlazekK | -.- Thats a 0x0F packet... | January 31, 2005, 12:46 AM |
NiNe | I dont think so =\ | January 31, 2005, 12:48 AM |
KkBlazekK | [quote author=NiNe link=topic=10376.msg97516#msg97516 date=1107132327] 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 [/quote] | January 31, 2005, 12:52 AM |
NiNe | Aww i see now, its cluttered stupid me | January 31, 2005, 12:53 AM |
KkBlazekK | Bnet usally sends 0x0F User in Channel in one big clump. | January 31, 2005, 12:54 AM |
JoeTheOdd | 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]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[/code] Right? | January 31, 2005, 2:49 AM |
HdxBmx27 | 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] 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[/code] as such, works perfectly for me. [quote] Ah, wonderful. Another reason that packets suck and CSB owns.[/quote] 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)~-~ | January 31, 2005, 4:13 AM |
tA-Kane | [quote author=JoeTheOdd link=topic=10376.msg97556#msg97556 date=1107139768] 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.[/quote]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!!!" | January 31, 2005, 7:34 AM |
kamakazie | [quote author=tA-Kane link=topic=10376.msg97596#msg97596 date=1107156898] [quote author=JoeTheOdd link=topic=10376.msg97556#msg97556 date=1107139768] 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.[/quote]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!!!" [/quote] 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. | January 31, 2005, 4:09 PM |
Myndfyr | [quote author=JoeTheOdd link=topic=10376.msg97556#msg97556 date=1107139768] 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. [/quote] 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. | January 31, 2005, 5:38 PM |