Erick Rojas wrote:
> Thank you very much Mark, yes are right, because
> i have in another message
>
> [java] <got-message-trailler>
> [java] 34
> [java] </got-message-trailler>
> [java] </log>
> [java] error unpacking field 49
>
> and the channel trunk the message remove the final ascii character 4
> , do you know if i can modify the BASE24TCPChannel? ,or how i can
> add (for example to the NACCChannel)the ETX?
Modifying the code is of course a possibility, however I would first
ask the owner of the system that is responding *without* the expected
ETX to add it. This way both ends of the conversation will agree and
all is well.
I don't like code that absorbs bytes that it is treating as (for
example) an ETX without actually checking that the byte absorbed is an
acceptable ETX value.
If the ETX is truly optional (it appears not) and you want to allow your
responder to get away without supplying the ETX, then :-
Extend BASE24TCPChannel and drop the 'trailler' processing from it's
getMessageLength() *and* getMessageTrailler() methods. This way your
sent message will have the ETX (the responder is coping with them
already), but the received messages will not.
I think it much better to stick to the message specification and *make*
the responder build a correctly structured message. I would also change
the getMessageTrailler() method to check that the byte it absorbs as the
ETX really is an ETX (x'03') and throw an Exception if it is not correct.
If you leave the send/get ETX processing unbalanced you are setting
yourself up for a fall later! If a well meaning programmer at the
responders site suddenly realises that they should have been sending the
ETX all along and simply corrects their code.
One other option is to drop the ETX processing from both sides of this
message exchange, it seems unnecessary and is causing you grief. An
agreement between both systems is the important aspect.
>
>
>
> Thanks again Mark!.
>
> Have a nice week!
>
>
>
>
>
>
> --- In jpos-dev <at> yahoogroups.com, Mark Salter <marksalter <at> ...> wrote:
>> Erick Rojas wrote:
>>
>>> no, the field 63 starts from
>> yes, see below...
>>> 102& 00
>>> 00c0 30 30 35 30 30 31 30 32 21 20 51 31 30 30 30 30 00500102!
> Q10000
>>> 00d0 32 20 39 20 21 20 51 32 30 30 30 30 32 20 30 34 2 9 !
> Q200002 04
>>> 00e0 21 20 30 34 30 30 30 32 30 20 20 20 20 20 20 20 ! 0400020
>
>>> 00f0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 21 20
> !
>>> 0100 43 30 30 30 30 32 36 20 37 39 38 20 20 30 30 31 C000026
> 798 001
>>> 0110 20 20 20 20 20 20 20 20 20 20 30 20 20 31 20 30
> 0 1 0
>>> 0120 20
>> We are agreeing, I pointed to the hex values, you have started with the
>> ascii representation. Ascii length c'102' = x'313032'.
>>
>>>
>>> with the sniffer i found that the host don´t send me a ETX, but i
>>> in the request send the ETX.
>>>
>>> 0000 00 00 01 00 00 00 c0 7e 20 00 01 00 08 00 45 00 .......~
> .....E.
>>> 0010 01 58 9c 0a 00 00 3e 06 6e 5e 80 24 28 0b be 0a
> .X....>.n^.$(...
>>> 0020 0a fe 1d 44 12 4b 30 3e 9a 09 e7 37 09 ae 50 18
> ...D.K0>...7..P.
>>> 0030 2c cc 0f 2c 00 00 01 2e 49 53 4f 30 32 34 30 30
> ,..,....ISO02400
>>> 0040 30 30 37 37 30 32 31 30 33 32 33 41 38 34 38 30
> 00770210323A8480
>>> 0050 32 45 38 31 38 30 30 32 30 30 30 30 30 30 30 30
> 2E81800200000000
>>> 0060 30 30 30 30 30 30 30 30 34 34 31 32 30 35 31 38
> 0000000044120518
>>> 0070 35 30 30 31 30 30 30 30 38 39 31 32 35 30 30 31
> 5001000089125001
>>> 0080 31 32 30 35 31 32 30 34 31 32 30 34 39 30 38 30
> 1205120412049080
>>> 0090 30 33 37 34 31 35 32 33 31 30 39 33 37 36 38 30
> 0374152310937680
>>> 00a0 35 37 38 3d 31 30 30 37 31 32 36 30 30 30 30 30
> 578=100712600000
>>> 00b0 38 36 33 30 30 30 30 30 20 20 20 20 20 20 20 20 86300000
>
>>> 00c0 20 20 20 20 30 30 30 30 30 30 31 34 30 30 30 30
> 000000140000
>>> 00d0 30 30 30 31 20 20 20 20 20 20 20 20 30 32 37 32 0001
> 0272
>>> 00e0 30 38 32 32 30 34 20 20 20 20 20 20 20 20 20 20 082204
>
>>> 00f0 20 20 20 20 20 20 20 20 20 20 38 34 30 31 30 32
> 840102
>>> 0100 26 20 30 30 30 30 35 30 30 31 30 32 21 20 51 31 &
> 0000500102! Q1
>>> 0110 30 30 30 30 32 20 39 20 21 20 51 32 30 30 30 30 00002 9 !
> Q20000
>>> 0120 32 20 30 34 21 20 30 34 30 30 30 32 30 20 20 20 2 04!
> 0400020
>>> 0130 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
>
>>> 0140 20 20 21 20 43 30 30 30 30 32 36 20 34 34 34 34 !
> C000026 4444
>>> 0150 20 30 30 31 20 20 20 20 20 20 20 20 20 20 30 20 001
> 0
>>> 0160 20 31 20 30 20 20 1 0
>> So your field 63 (ending in x'2020' or c' ')is echoed back, but the ETX
>> is missing.
>>
>> In your previous post you included the text :-
>>
>> <got-message-trailler>
>> 20
>> </got-message-trailler>
>>
>> What code writes this log entry, is it your Channel?
>> It seems to be taking this character space (c' ' = x'20') as the
>> 'trailler' (which I read ETX) thus truncating the response message, and
>> causing the Exception as field 63 now only has 101 bytes available,
>> instead of the 102 it's length structure indicates.
>>
>> This code should perhaps check the 'trailler' is the expected byte value
>> and reject the message as invalid rather than try to parse it.
>> Alternatively because the message does not end in an ETX, treat it as
>> having no 'trailler'.
>>
>>> how you can found the message length?
>> The message length will be specified just before the start of the
>> message and is probably stripped from this dump.
>>
>>> I need use another channel for the host response or change the
> channel?
>> You have two choices...
>>
>> 1. Amend the channel to treat the ETX as optional, only stripping off
>> the ETX if it is really present.
>>
>> 2. Ask the responder to conform to the message specification and add the
>> expected ETX.
>>
>> --
>> Mark
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
--
Mark
RSS Feed