Need Help Parsing data from Winsock

I am reading the data in a string now i want loop through each char if chr equals to Chr(&h Anything) then the next two bytes will be the length of the string in network byte order how should i read all the strings to an array ?

This is what i have tried

Private Function SomeFunction(ChrToLookFor As String,data As String) As String()
On Error Resume Next
Dim i As Integer, result() As String, index As Integer
For i = 1 To Len(data)
If Mid(data, i, 1) = ChrToLookFor Then
ReDim Preserve result(index) As String
result(index) = Mid$(data, i + 3, Asc(Mid$(data, i + 1, 1)) * 256 + Asc(Mid$(data, i + 2, 1)))
i = i + 3 + Asc(Mid$(data, i + 1, 1)) * 256 + Asc(Mid$(data, i + 2, 1))
index = index + 1
End If
Next
SomeFunction = result
End Function

Bytes and chr() is two different things.
A character can be more than one byte.
So if your character is 2 bytes you want half your chr and half the other chr?

I don't understand what you want either describe using bytes only or chars only.

Sorry i seemed to be in a rush when making this thread anyways im gonna rephrase i want loop through each character in a string if the character is certain character the next chr's represent the length of the string followed by the actual string. i hope now i am making some sense xD

When your data contains binary information such as length prefixes you do not want to use String variables at all.

Winsock.GetData string implies conversion from network bytes in localized ANSI to Unicode, which can result in unexpected distortion. Re-distorting back by using Asc() will work... except when it fails.

Skip all of this and receive into Byte arrays and process those.

i wish i could do but i believe i have to rewrite over 150+ lines of code if i start over most of my the work is done other than this and i'd like to continue with the best possible solution in my current case D:

Then you need to read your chars into binary bits then get the number

Perhaps posting your 150 lines of code in here would give us a chance to help you modify what needs to be modified.
Using bits works but is a slower if your going to process lots of information and as dilettante said down the road it might fail and that will be a bigger headache.

Edit:
Why *256?
Also your using string to make an addition "+"...

example: mid$() + mid$()
which is: 1 + 1 = 11

Ok since you want to do it the wrong way :) I'll give you an example that would work (hopefully all the time).

Code:

---

Private Sub Command1_Click()
Dim Data As String
Dim ChrToLookFor As String
Dim StrLength As Integer  'remember your string cannot exceed the integer's limit.. if it will then change to long
Dim StringWeWereLookingFor As String

  Data = "blah blah blah blah" & "@" & Chr(34) & "I wanted apples in my lunch mommy!" & " blah blah blah"
  ChrToLookFor = "@"      'this is the character that splits the string from the others
 
  '----------------------------------
  'This is just for your information
  'StrLength = 34          'which will be " which is 34... Chr(34) = "
  '----------------------------------
 
  i = 1
 
  Do Until i = Len(Data)
    If Mid$(Data, i, 1) = ChrToLookFor Then
      StrLength = Asc(Mid$(Data, i + 1, 1))
      StringWeWereLookingFor = Mid$(Data, i + 2, StrLength)
    End If
    i = i + 1
    DoEvents
  Loop
 
  MsgBox "String Length: " & StrLength & vbNewLine & "String: " & StringWeWereLookingFor
End Sub

---

I won't have much time to help more, but if I do let me know as soon as possible (today) what else you are missing or what am I missing in my example.

If there is going to be Unicode characters you will have to use AscW instead of Asc.

Quote:

---

Originally Posted by TeraBaap

...... but i believe i have to rewrite over 150+ lines of code if i start over most of my the work is done other than this and i'd like to continue with the best possible solution in my current case D:

---

Better to re-write 150 lines than spend 150 hours debugging later on. (IMHO) Sounds to me like you've built the House and are now starting on the foundations. Take good note of Dilettante's comments.

Quote:

---

Originally Posted by TeraBaap

i wish i could do but i believe i have to rewrite over 150+ lines of code if i start over most of my the work is done other than this and i'd like to continue with the best possible solution in my current case D:

---

This is the wrong thinking. I recently had to rewrite a portion of my own Winsock application because I clumsily kept tacking on features to its file transfer protocol which resulted in a huge mess that was difficult to debug. It took me nearly two weeks and a little pain to rewrite it from scratch but it had to be done to spare me even more headaches in the future. Mine was way more than 150 lines of code. It was closer to 2000 lines of code. My rewrite resulted in less code that's better organized something like 800 lines. When something has to be done, it just has to be done.

That being said, the way you designed your protocol is not very good. Firstly, you're searching for a length prefix inside a data stream. Assuming you're using the TCP protocol which is reliable, you shouldn't be doing this. Every stream of data you send should start with a known header and from there you can use a length field to determine how much data your payload has and you use the length of the header to know where the payload starts. From there you can determine where the next piece of data should be in the stream which should also start with a header. Every time you have a full message in the stream, you can remove it from the stream so the stream again begins with a header. You should never have to scan a stream for data. That would make your protocol terrible slow and not to mention, unreliable.

Also, like dilettante said, you really shouldn't be playing around with binary data inside a string. If you like, I can show you the correct way to convert a series of bytes into a Long and vice versa.

http://en.wikipedia.org/wiki/Real_Ti...aging_Protocol

03 00 0b 68 00 00 19 14 00 00 00 00 02 00 0C 63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05

. . @ I . . . . . . . . . . . . c r e a t e S t r e a m . @ . . . . . . . .

Quote:

---

The packet starts with a Basic Header of a single byte (0x03) where the 2 most significant bits (b00000011) define a chunk header type of 0 while the rest (b00000011) define a Chunk Stream ID of 3. The 4 possible values of the header type and their significance are:

• b00 = 12 byte header (full header).
• b01 = 8 bytes - like type b00. not including message ID (4 last bytes).
• b10 = 4 bytes - Basic Header and timestamp (3 bytes) are included.
• b11 = 1 byte - only the Basic Header is included.

The last type (b11) is always used in the case of aggregate messages where, in the example above, the second message will start with an id of 0xC3 (b11000011) and would mean that all Message Header fields should be derived from the message with a stream Id of 3 (which would be the message right above it). The 6 least significant bits that form the Stream ID can take values between 3 and 65599. Some values have special meaning like 1 that stands for an extended ID format, in which case there will be 2 bytes following that. A value of 2 is for low level messages such as Ping and Set Client Bandwidth.
The next bytes of the RTMP Header (including the values in the example packet above) are decoded as follows:

• byte #1 (0x03) = Chunk Header Type.
• byte #2-4 (0x000b68) = Timestamp delta.
• byte #5-7 (0x000019) = Packet Length - in this case it is 0x000019 = 25 bytes.
• byte #8 (0x14) = Message Type ID - 0x14 (20) defines an AMF0 encoded command message.
• byte #9-12 (0x00000000) = Message Stream ID. This (strangely) is in little-endian order

---

This is just an example of a packet i am trying to parse .

Thanks to everyone for replying i will surely give a try reading the data into a byte array instead of a string :)

Quote:

---

Originally Posted by Niya

This is the wrong thinking. I recently had to rewrite a portion of my own Winsock application because I clumsily kept tacking on features to its file transfer protocol which resulted in a huge mess that was difficult to debug. It took me nearly two weeks and a little pain to rewrite it from scratch but it had to be done to spare me even more headaches in the future. Mine was way more than 150 lines of code. It was closer to 2000 lines of code. My rewrite resulted in less code that's better organized something like 800 lines. When something has to be done, it just has to be done.

That being said, the way you designed your protocol is not very good. Firstly, you're searching for a length prefix inside a data stream. Assuming you're using the TCP protocol which is reliable, you shouldn't be doing this. Every stream of data you send should start with a known header and from there you can use a length field to determine how much data your payload has and you use the length of the header to know where the payload starts. From there you can determine where the next piece of data should be in the stream which should also start with a header. Every time you have a full message in the stream, you can remove it from the stream so the stream again begins with a header. You should never have to scan a stream for data. That would make your protocol terrible slow and not to mention, unreliable.

Also, like dilettante said, you really shouldn't be playing around with binary data inside a string. If you like, I can show you the correct way to convert a series of bytes into a Long and vice versa.

---

Thanks i'd appreciate if you could show me a correct way to convert the bytes into any other data type that would be helpfull :)

Quote:

---

Originally Posted by TeraBaap

Sorry i seemed to be in a rush when making this thread anyways im gonna rephrase i want loop through each character in a string if the character is certain character the next chr's represent the length of the string followed by the actual string. i hope now i am making some sense xD

---

I showed you an example, but I guess you did not explain well, did you try it?
Also I would listen to dilettante and niya and just rewrite what has to be re-written to send/receive in bytes, in the end it will be a lot fast and you'll avoid re-writting your whole project (if its not done already) it's better now then later.