LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

what is the best way to parse TCP data packets?

So I am trying to read packets of TCP data and the size of the packet changes depending on the message sent.
Is there a better way to parse this data?

 

I was looking at clusters and flatten/unflatten to string but not sure which would be the most efficient method.

 

What I am trying to do is extract data from packets which indicate that is was processed from a device at address 20h
(address indicator) and then read the number of bytes as indicated by  size (size indicator) but the compare for
address 20 and the read size number of bytes is not working.

 

 

tcp-parsing.jpg

 

 

What is the best way to do this?

 

thanks

0 Kudos
Message 1 of 50
(11,273 Views)

Is there anything in common to all messages?

 

Typically there is, so that's where you start.  A beginners guide to TCP/IP

 

TIP: most of your sequence structures are doing absolutley nothing.

 

When using variably sized messages, there is usually a three-step process:

 

1... Read a HEADER, of a fixed size, which provides the basic message type, and its size.

2... Unflatten the header string into a header CLUSTER, which usually helps to parse it.

3... Use the size stated in the header to read the payload.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 2 of 50
(11,249 Views)

@robojeff wrote:

What is the best way to do this?

 


  • What is the point of all that clutter with sequence frames??? Execution order is fully determined by dataflow, so they can all be deleted
  • What is the point of the waits in the last two frames? Are they needed? Why?
  • The first four reads are all fixed size, so it would seem easier to simply read 27 bytes and parse it all at once.
  • Are you sure the size is a hexadecimally formatted character (0..F). Could it be a binary byte (0...255)
  • What's up with all these coercion dots?
  • What's in the false case?
  • Where is the rest of the code? (e.g. where do you open the connection?) Can you attach the actual VI?
0 Kudos
Message 3 of 50
(11,234 Views)

Thank you for the responses...

 

OK, I have stripped out the flat structures. When I was first putting these together, I was concerned

about settling time of when a TCP packet response was posted which is why I had set these up with the waits.

 

Reading the Header and then flattening it into a header cluster makes sense to me and will search for an example

on how to do this...

 

A little definition of what  Iam trying to accomplish:

There are 4 commands that set up the device to transmit TCP data
(Poll Headboxes, List Headboxes, Enable Events, & Start Sampling)
and one command to stop the device from sending more data (Stop Samplinig)

 

I am sending the four commands and reading the TCP response which I am dumping into
indicators.

 

 

imptest-1.jpg

 

 

 

In the While loop:

I am reading the data samples and reading the following data:

24 bytes = TCP wrapper which I am not concerned with.
1 byte = Size of the command.
1 byte = pad (ot used)
1 byte = Address (I only want to parse data that is coming from address 0x20 (20h).

 

 

In the case structure:

If the address = 0x20 (TRUE) then I want to read (Size) number of bytes and then issue a stop sampling command.


If the address <> 0x20 (FALSE) then I want to read (Size) number of bytes and continue sampling data.

 

imptest-2.jpg

 

Questions...

1. When I send each of the four commands to start the data sampling, do I need to follow each of these commands with a TCP read in order to

   Flush the TCP stream (like is needed for serial communications)?

 

2. When I am parsing the SIZE, I am trying to convert this to hexadecimal to set the number of bytes to read but this is not working

     correctly. Should I be doing this another way?  (the size ot the remaining data in the TCP packet varies and is specified by SIZE).

 

3. I want to know when a packet of data is coming from the device at address 0x20 (Address) but this does not seem to be working either.

    Am I setting this compare up correctly?

 

0 Kudos
Message 4 of 50
(11,191 Views)

You are reading only 1 byte, then trying to convert that as a hexadecimal string to a number.

 

I really doubt the data is being sent as a hexadecimal string.

 

Typecast that 1 byte to a U8 number.

 

Also, be sure the 20 you have in the string constant is set for hex display and not normal display.

Message 5 of 50
(11,177 Views)

Is there anything in common to all messages?

 

Typically there is, so that's where you start.  A beginners guide to TCP/IP

 

TIP: most of your sequence structures are doing absolutley nothing.

 

When using variably sized messages, there is usually a three-step process:

 

1... Read a HEADER, of a fixed size, which provides the basic message type, and its size.

2... Unflatten the header string into a header CLUSTER, which usually helps to parse it.

3... Use the size stated in the header to read the payload.

===================================

 

Are there any examples on how to read a header and unflatten the header string into a header cluster?

 

thanks

0 Kudos
Message 6 of 50
(11,135 Views)

The topic of this is not TCP, but it does show how to FLATTEN a cluster for TCP usage.

 

To UNFLATTEN, simply use an UNFLATTEN function, wire the cluster into the TYPE input and the received string into the STRING input, and out comes a cluster.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 50
(11,129 Views)

Ok, so if I were to change my VI where I do a TCP Read to read 27 bytes what do I output the data to,

a string?  (Not sure how to do that...)

 

unflatten.jpg

0 Kudos
Message 8 of 50
(11,114 Views)

Here's the basic idea:

 

You have a FIXED SIZE HEADER.  You don't absolutely HAVE to, but it's better to use a TYPEDEF for that (see the article about fragile code).

 

On the SENDING side, you have a FIXED-SIZE header and a variable-sized payload.

 

The OPCODE in the header tells you what kind of payload to expect.

 

FLATTEN the payload into a string.

 

CONSTRUCT the header, using the size of the payload.

 

FLATTEN the header into a string.

 

CONCAT the two strings into one message.

 

SEND the string over the TCP link.

 

 

Link.PNG

 

 

On the RECEIVING side, RECEIVE the fixed-size header (you should still calculate the fixed size - see the FRAGILE article).

 

UNFLATTEN the string into a header cluster.

 

Use the PAYLOAD SIZE from the cluster to determine how much payload to read.

 

Read that much more payload.

 

Use the OPCODE and PAYLOAD to do something useful.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 9 of 50
(11,097 Views)

Thanks  for the info...

 

Sorry if I am a little slow but these are new concepts to me.

 

I have been reading through your post and the non fragile code and still trying to figure this out.

 

Example #1 explains receive a packet header ...

 

So what I want to do is to receive a packet header,
(all hexidecimal big endian values) consisting of a cluster of:

 

 6 words (TCP wrapper),
 1 word (Seq. ID),
 1 word (pad)
 1 word (Length)
 1 byte (event ID)
 1 byte (event type)
 2 words (event count)
 1 word (size)
 1 byte (board address)
 1 byte (pin info)

 

This is my fixed response header...

 

Question 1: How do I create this TYPEDEF header/cluster?

 

Once I can read this header, I need to flatten it to a string and determine if it is from address 20h
and then read <size> number of bytes.

 

Question 2: How do I convert the board address into a hexidecimal number that will allow me to know if a packet is coming from board adress 20h?

 

Question 3: How do I convert the size into a hexidecimal number that will allow me to know how many bytes of data to read?

 

Thanks again

0 Kudos
Message 10 of 50
(11,049 Views)