sending message header before message length

[Zablon Ochomo]

Someone help me send this message properly.
What am sending now
length   header        DE0  DE11    DE12              DE24
000048 ISO8583-93 1804 032336 130520134318 831

what is expected
header        length   DE0  DE11    DE12              DE24
ISO8583-93 000048 1804 032336 130520134318 831

Is it something I can do by modifying the channel implementation or how does jPOS handle it?

[Zablon Ochomo]

Another way it can be put is how do we implement a start of message string?
The string is 10 character long. All messages are required to have a 10 character string at the start.
I think this is different from header string. How does jPOS handle this case?

[Alejandro Revilla]

You can create your own channel and override the sendMessageLength and getMessageLength methods so that they plug that fixed header.

--
@apr

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Zablon Ochomo]

I have added this line before sending message length:
serverOut.write("ISO8583-93".getBytes());

and changed getMessageLength from
serverIn.readFully(b,0,6);
to
serverIn.readFully(b,10,16);

Is this OK?

[Mark Salter]

On Monday, May 20, 2013 2:03:02 PM UTC+1, Zablon Ochomo wrote:

I have added this line before sending message length:
serverOut.write("ISO8583-93".getBytes());

 

Watch your charset, it might be important to someone!

 

and changed getMessageLength from
serverIn.readFully(b,0,6);
to
serverIn.readFully(b,10,16);

Is this OK?

 

I have to doubt it ...

... is the field b used for anything else at all?

How big is it?

 

 

As an aside....

What did your testing show?

If you do want me to make up your test results...

... yes it worked perfectly.

:-)

 

--

Mark

[Zablon Ochomo]

Finally some hope!
I made this changes to getMessageLength
int l = 0;
        byte[] b = new byte[6];
        byte[] bb = new byte[16];
        while (l == 0) {
            serverIn.readFully(bb,0,16);
           
            System.out.println("REC Head text: " + new String(bb));
            for(int c=10; c<=15; c++)
            {
                b[c-10] = bb[c];
            }
            try {
                if ((l=Integer.parseInt(new String(b))) == 0) {
                   
                    serverOut.write(b);
                    serverOut.flush();
                }
            } catch (NumberFormatException e) {
                throw new ISOException ("Invalid message length "+new String(b));
            }
        }
        System.out.println("REC Message length: " + l);
        return l;

I read the whole first part of 16 bytes and get the header+length
I got response but can pass as ISOMsg object! From above code it prints

REC Head text: ISO8583-93000052
REC Message length: 52

then hangs!

Here is my wireshark (added spaces for readerbility)
>> ISO8583-93000049 1804 0145245 130522101905 831
<< ISO8583-93000052 1814 0145245 130522101905 831 800

Something strange on this message is that my packager pre-appends a 0 on the STAN. This could be a problem?

[Zablon Ochomo]

Sorry,
I meant:
I got response but cannot pass as ISOMsg object!

[Zablon Ochomo]

Another sorry!
the 0 on the STAN is a problem with wireshark plain text not the message. The message is OK but I cant pass it back.

[chhil]

Hi,

Length of string ISO8583-9300004918040145245130522101905831 is 42, your length indicator indicates 49
Length of string ISO8583-9300005218140145245130522101905831800 is 45, our length indicator indicates 52.

For whatever reason the difference between actual length including the length after header is off by 7.

You return this larger length then what is actually the length of the message, telling your channel to wait for more bytes then that are there andthats probably why it appears to "hang" waiting for more bytes.

-chhil

[Zablon Ochomo]

Hi,

I got it!

The message length was the issue.

On sending i add 16 to the length so on receive I also subtract 16 from incoming length!

On your question above is that the server is not strictly ISO 8583.

1. It expects Header before length

2. length shoul be N6 so we zero-pad

3. the length is for the whole string including HEADER+LENGTH+DATA

But after tweeking the sendMessageLength and getMessageLength jPOS still worked wonders :D

The code is below:
protected void sendMessageLength(int len) throws IOException {
        len += 16;
        try {
            System.out.println("SEND Message length: " + ISOUtil.zeropad(Integer.toString(len), 6));
        } catch (ISOException ex) {
            Logger.getLogger(BFUBChannel.class.getName()).log(Level.SEVERE, null, ex);
        }
        if (len > 9999)
            throw new IOException ("len exceeded");

        try {
            serverOut.write("ISO8583-93".getBytes()); // beging of message field
            serverOut.write(
                ISOUtil.zeropad(Integer.toString(len), 6).getBytes()
            );
        } catch (ISOException e) { }
    }
    /**
     * @return the Message len
     * @exception IOException, ISOException
     */
    protected int getMessageLength() throws IOException, ISOException {

        int l = 0;
        byte[] b = new byte[6];
        byte[] bb = new byte[16];
        while (l == 0) {
            serverIn.readFully(bb,0,16);
           
            System.out.println("REC Head text: " + new String(bb));
            for(int c=10; c<=15; c++)
            {
                b[c-10] = bb[c];
            }
            try {
                if ((l=Integer.parseInt(new String(b))) == 0) {
                   
                    serverOut.write(b);
                    serverOut.flush();
                }
            } catch (NumberFormatException e) {
                throw new ISOException ("Invalid message length "+new String(b));
            }
        }

        System.out.println("REC Message length: " + (l-16));
        return l-16;
    }

Thanks for helping.

--
Zablon Ochomo

[chhil]

You are welcome.

Though I am not sure why you have the following in your getmessagelength.

    if ((l=Integer.parseInt(new String(b))) == 0) {
                   
                    serverOut.write(b);
                    serverOut.flush();
                }

Secondly subtracting the 16 already consumed looks good, but the length of the data following is still 7 less (in the wireshark traces), not sure how or why it works for you.

Length of string ISO8583-9300004918040145245130522101905831 is 42, your length indicator indicates 49.
You do a 49-16 = 33, but actual data left [18040145245130522101905831] is 26 and if you return 33 you will be waiting for the next 7 bytes till a new message comes in and data from that will get used to complete the 33 bytes to receive.
-chhil

[Zablon Ochomo]

The code you pointed in the getmessagelength is from the CSChannel I started with. I will clean it by just having:

l=Integer.parseInt(new String(b)))

The wireshark dump is not properly done. I used copy clear text option. it does not consider the BITMAP and appears to introduce extra data.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org
 
You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users
 
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Zablon Ochomo

[chhil]

Yeah clean it up, if the length is 0, then you end up sending back a string of 0's to the host and method would return a length of -16 :)
For future postings, please do post complete/accurate dumps so it does not mislead/confuse.

Wireshark, select copy->Bytes (offset hext text) to get tcp headers  + data
Or go to the tree where the different layers are shown, select data then copy->Bytes (offset hext text) to get the data part (your message).

-chhil

[Zablon Ochomo]

Thanks.