Results 1 to 15 of 15

Thread: Need Help Parsing data from Winsock

  1. #1

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    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

  2. #2
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

    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.

  3. #3

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    Re: Need Help Parsing data from Winsock

    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

  4. #4
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Need Help Parsing data from Winsock

    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.

  5. #5

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    Re: Need Help Parsing data from Winsock

    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:

  6. #6
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

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

  7. #7
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

    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
    Last edited by Max187Boucher; Jul 26th, 2014 at 02:13 PM.

  8. #8
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

    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.

  9. #9
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

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

  10. #10
    PowerPoster
    Join Date
    Jul 2006
    Location
    Maldon, Essex. UK
    Posts
    6,334

    Re: Need Help Parsing data from Winsock

    Quote Originally Posted by TeraBaap View Post
    ...... 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.

  11. #11
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Need Help Parsing data from Winsock

    Quote Originally Posted by TeraBaap View Post
    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.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  12. #12

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    Re: Need Help Parsing data from Winsock

    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 . @ . . . . . . . .
    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 .

  13. #13

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    Re: Need Help Parsing data from Winsock

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

  14. #14

    Thread Starter
    Member
    Join Date
    Jul 2013
    Posts
    35

    Re: Need Help Parsing data from Winsock

    Quote Originally Posted by Niya View Post
    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

  15. #15
    PowerPoster
    Join Date
    Aug 2011
    Location
    B.C., Canada
    Posts
    2,887

    Re: Need Help Parsing data from Winsock

    Quote Originally Posted by TeraBaap View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width