| Author |
Message
|
| JULLRICH |
 Posted: Wed Jun 17, 2009 3:11 am Post subject: parsing hex to number using ASCII table |
 |
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Hello guys
I do have an incoming TCPIP Record that needs to be parsed using a MsgSet defined in the TCPIPInputNode
it is an msg with encoded length
example msg 1:
000C0001AB001234
where:
000C is hex and represent the length of non hex string 0001AB001234
example msg 2:
000D0001AB0012345
where:
000D is hex and represent the length of non hex string 0001AB0012345
using the ascii table you can find the correlation between 000C / 000D on one hand and the length on the other hand
for this pls. visit http://www.asciitable.com/
you will find out:
000C can be translated to 12 and
000D can be translated to 13
I don't know how to parse such messages. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jun 17, 2009 3:13 am Post subject: Re: parsing hex to number using ASCII table |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JULLRICH wrote: |
| I don't know how to parse such messages. |
Either:
Substring the input to remove the leading number, and cast it
or:
Define a message set with 2 fields; one (length) as a number, a second (payload) being the string.
Other, potentially better, solutions are undoubtably possible.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Wed Jun 17, 2009 4:50 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
First possibility will not work, because the message will not leave the TCPIPnode without parsing
Second possibility will not work without having the length defined for second field!
Last edited by JULLRICH on Wed Jun 17, 2009 4:55 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 4:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JULLRICH wrote: |
| First possibility will not work, because the message will not leave the TCPIPnode without parsing |
Yes it will - it doesn't need to be parsed, it needs to be placed in a message domain.
| JULLRICH wrote: |
| Second possibility will not work without having the length defined for second field! |
Really?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Wed Jun 17, 2009 5:25 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
This is a stream with 4 Msgs:
000C0001AB001234000D0001AB0012345000C0001AB001234 000B0001AB00123
Such streams arriving at TCPIPInput. It is NOT a single Msg, it is a data stream with several messages.
Now, you need to truncate the stream with a MessageSet into several messages. For doing this you must find a place where to cut the stream into messages. Question: where to cut the stream without having the length of the data?
Additionally to that, I don't know how many message are coming.
Once there is a single msg, once there are several messages in a single stream.
There is no finish of data also, because the TCPIP connection is still open when the message should have been processed! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2009 5:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Build a message model that matches your single message, using the length encoding.
Tell the TCPIPInput node to use that.
See what happens. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JULLRICH wrote: |
| Now, you need to truncate the stream with a MessageSet into several messages. For doing this you must find a place where to cut the stream into messages. Question: where to cut the stream without having the length of the data? |
Because the start of the stream is a length indicator of known format.
| JULLRICH wrote: |
Additionally to that, I don't know how many message are coming.
Once there is a single msg, once there are several messages in a single stream. |
Still not a problem
| JULLRICH wrote: |
| There is no finish of data also, because the TCPIP connection is still open when the message should have been processed! |
But there is a discrete POST containing 1-n messages which you are terming "a stream". Or are you assembling the data on a byte by byte basis as it leaves the node?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Wed Jun 17, 2009 5:40 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Jeff:
Yes, that is what I tried to do!
That is the way I figured out.
This is working for other data streams too.
But how to translate '000C' to 12 or '000D' to 13 automatcially?
Nothing was working.
Sometimes the parser gots C as length value sometimes 0 ... mostly nothing. 
I'm sure, that it's only a small setting.
Thx
for help!!!!
Vitor:
TCPIPNode will open an stream for getting data continously. So the datastream is growing when not parsing msgs from it. You have to cut it into peaces using a fixed delimiter, using the end of stream, using an fixed defined length or using an message set.
I'm nearly sure, that I have to choose the message set for doing this.
Data will leave the TCPIPInput only, when successfully separated into messages. Otherwise data is going to the failure terminal.
So I can't do this somewhere else then in the message set.
Last edited by JULLRICH on Wed Jun 17, 2009 5:52 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JULLRICH wrote: |
Yes, that is what I tried to do!
That is the way I figured out. |
Gosh!!! 
I was actually being slightly sarcastic when I said that; you're a braver man than me!
| JULLRICH wrote: |
But how to translate '000C' to 12 or '000D' to 13 automatcially?
Nothing was working.
Sometimes the parser gots C as length value sometimes 0 ... mostly nothing. |
I'm not surprised. If you're assembling the message "by hand" like this, message interpretation will be the responsibility of your code.
| JULLRICH wrote: |
| I'm sure, that it's only a small setting. |
I wish I had your confidence in that. And wish you good luck with your solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2009 6:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Maybe I've missed a crucial point here.
Does the TCP message contain a *character representation* of the number - that is, actually holds the ascii 30303043 rather than a binary 000C ? |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Wed Jun 17, 2009 6:41 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Testdata is:
000C0001AB001234
000C describes the length of the datafield that is following.
000C is build by an very old application based on the ASCII-table.
In the ASCII-table you have to look for the line where Hex = 0C then move to column dec, and you will find 12 ... for Hex = 00 you will find 0 in column dec.
=>
001F has to be translated to a length of 31
means:
the msg contains '001F' and 31 (Var)Chars
OR:
003F has to be translated to a length of 63
means:
the msg contains '003F' and 63 (Var)Chars
ASCII-table:
http://www.asciitable.com/ |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2009 6:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm well aware of how to convert binary to ascii, and ascii to numeric values.
I covered that in my high school "intro to computers" class.
I'm asking you, very specifically, if the bytes that start the TCPIP stream are '000C' or '30303043'.
One is easy to model, the other is harder.
If you don't know the answer, and don't know how to find out the answer, you probably need to tell your boss to assign someone else to this project, or at least to assist you. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 17, 2009 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JULLRICH wrote: |
000C is build by an very old application based on the ASCII-table.
In the ASCII-table you have to look for the line where Hex = 0C then move to column dec, and you will find 12 ... for Hex = 00 you will find 0 in column dec.
|
Erm.... 0C is 12 in hex. 1F is 31 in hex. You don't need to look anything up to convert them. It's a numeric field indicating the length of the following string.
That's been my point about modelling the message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Wed Jun 17, 2009 7:42 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Jeff:
when tracing an stream you will see X'000C303030313A41303031323334' as an sampleMsg.
So '000C' is correct answear. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 17, 2009 8:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
|
|
