what is the best way to parse TCP data packets?

[CoastalMaineBird]

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

I wouldn't worry about the TYPEDEF part until you get it working.

The reason you eventually want a TYPEDEF is that so when (not IF) the thing changes, you change the typedef in ONE place and everybody that uses it follows the changes.

But for right now, just make a plain cluster.

If you're trying to match an existing format, then you have to match the order and the size of things in your header.

Make a cluster and put your items in it.  Make sure that you're using I32 or U8 or whatever to match your spec.

Make sure you can unflatten your received string using that cluster and see if you receive the data right.

Then we'll go from there.

[CoastalMaineBird]

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?

I don't understand the question.  It's already a hex number, in one byte.  Create a U8 constant on your diagram, set its value to 32 (or set its DISPLAY FORMAT to hex, and its value to 0x20), and compare the constant to the value you receive, with an EQUALS operation.

[robojeff]

Thanks...

Does this look correct?

[CoastalMaineBird]

1... Well, it's not exactly wrong, but there's no reason for you to BUILD that cluster every time, since you're just using the data type.   Make a cluster on the front panel (that's the first step in making a typedef) and use it.

2... It's not clear whether the "20" in your constant is hex or not.  Show the radix on that constant.

3... If youre data source sends data that might be for someone else (besides device 20) you need to read the payload part of such a message anyway, and discard it.

If you don't read it, the thing sill get out of synch.

4... You are extracting the B-addr from the constant that you built.  Since you built it with a B-ADDR of 0, it's highly likely that you get out a B-ADDR of 0.

5... You're not even using the output of the UNFLATTEN operation.   I don't know what that LENGTH IN BYTES is, but you didn't even connect the unflattened cluster.

[robojeff]

Thanks Steve-

If I understand correctly, I remade the cluster from controls on the front panel and showed their radix as shown below.

Are these fields in the cluster as defined by the front panel controls, still contants where the B-addr will be 0 or will these

fields on the front panel be populated with the values from the folowing block diagram code?

I know t hat I need to add a typedef for the payload but because this can be different depending on the length that is pulled from the TCP packet,

how do I set this cluster size up to change as needed?

By the way, the True case only sends a stop sampling command and sets the while loop exit to TRUE.

Thanks again Steve

[CoastalMaineBird]

Are these fields in the cluster as defined by the front panel controls, still contants where the B-addr will be 0 or will these

fields on the front panel be populated with the values from the folowing block diagram code?

You still need to wrap your head around dataflow - it sounds like you're still floundering.

It's real simple: the fields you defined on the front panel are called CONTROLS, and will be at their default values unless:

1... The user changes them.

2... You wire something to a local variable connected to one of them.

3... You wire something to a VALUE property node of one of them.

--- As I said before, there is no value in actually BUILDING (using the BUNDLE function) this cluster on the diagram.  SImply plop a CLUSTER on the front panel, and drag the items into that cluster, in order.  If you make a mistake, pop up on the cluster an REORDER ITEMS IN CLUSTER.

This is the first step in making a typedef, but you don't have to go that far right away.

--- You've improved the code somewhat - you're now using the UNFLATTEN function correctly.  Understand what happens there: you put in a STRING - this string contains the real data.  You also put in a DATA TYPE (your header cluster).  The VALUES of this cluster don't matter - you are telling the function to take the STRING and interpret it as a cluster of an I16 and a U8 and an I32, whatever.  The VALUES of that cluster are irrelevant, what is important is the data type of the structure.

What comes out is a cluster of the same DATA TYPE as the one you gave it, but populated with values extracted from the string.

If you have any string data left over, it comes out the REMAINDER OF STRING output, but that shouldn't happen in your case.

You are correctly using the B-ADDR and length from that unflattened string.

I know that I need to add a typedef for the payload but because this can be different depending on the length that is pulled from the TCP packet,

how do I set this cluster size up to change as needed?

You do not change a given cluster's size - that cannot be done by the program.  In my example above, I use the OPCODE from the header to determine WHICH way to interpret the payload.  You READ the payload the same in all cases, but if the OpCode is 1, then the payload gets unflattened into structure #1, if the OpCode is 2, then the payload gets unflattened into structure #2, etc., etc.

In other words, you take the same payload string, and unflatten it using structure 1, or structure 2, based on something that's in the header.

I don't know what you're sending, but it looks like the EVENT TYPE or the EVENT ID in the header might tell you which way to go.

[robojeff]

Thank you for your guidance and patience.

I think that I am starting to get it but still need to play around with the variable sized response payload ...

[CoastalMaineBird]

One of the things about the FRAGILE article is that you shouldn't plop down the constant "27" when asking to read the header.

Look at my example in the article - it flattens the cluster into a string, and then takes the string length.

If you've done everything right, you will get "27" for that result, but if anything changes, you're already set for it.

In any case, the real answer is not what I think, but does it work?
If you pop up on the OUTPUT of the UNFLATTEN function, and CREATE INDICATOR from it, then you should have a cluster that will show your header as you received it.

Can you read the header and does it show up correctly?

If so, you've done it right.

_________

The thing about the variable sized payload is that you need to have a cluster for each possible EVENT ID or EVENT TYPE (whatever distinguishes one from another).

Dependin on what the HEADER says, you interpret it one way or another.

[robojeff]

Thanks Steve

I can't try it right now as I just found out that my TCP device is broke and it will take a few days to get a replacement.

In the meanwhile I will continue to improve this code.

Thank you for all of your help!

[RavensFan]

Change the TCP packet control into a constant.  As was said earlier, you aren't doing anything with that control.  It is just being used to define the datatype.  So there is no reason to show that on the front panel.