Reached queue timeout

[sihameed]

Hi Igor,

We try use SocketQueue connect to our backend ISO.
Our backend IP is 10.225.16.48, and the service at the backend listening on port 333.

We start the SocketQueue with this below command:
node socketQueue.js --upstreamHost=10.225.16.48 --upstreamPort=333 --listenHttpPort=8080 --echoServerPort=333 --vv --logFile=log.txt

But, when we try to simulate send the request:
curl -H "Content-Type: application/json" -X POST -d '{ "0": "0800", "3": "1", "7": "1112070616", "11": "436014", "24": "1", "41": "1", "70": "001"}' http://127.0.0.1:8080

We got queue timeout.
We figure out, the SocketQueue doen't sent our requested message to our backend (10.225.16.48).

2017-11-12 08:26:20 - info: Writing to queue http:::1:57404 [0]
2017-11-12 08:26:20 - info: New queue item 2
2017-11-12 08:26:20 - info: Processing queue [pending 1 / total 1]
2017-11-12 08:26:20 - verbose: Queue keys dump: 2
2017-11-12 08:26:20 - info: Upstreaming data for http:::1:57404
2017-11-12 08:26:20 - verbose: [00560800...]
2017-11-12 08:26:55 - info: Queue notice: http:::1:57404 reached queue timeout
2017-11-12 08:26:55 - info: Dropping the client http:::1:57404
2017-11-12 08:26:55 - info: Client http:::1:57404 gateway timeout
2017-11-12 08:26:55 - info: Client http:::1:57404 event
2017-11-12 08:26:55 - verbose: Releasing terminal 00000003 with the key 2
2017-11-12 08:26:55 - info: Warning: client http:::1:57404 [queue id 2] terminated activity
2017-11-12 08:26:55 - info: Processing queue [pending 0 / total 0]
2017-11-12 08:26:55 - info: The queue is empty

N.B:
-No firewall between SocketQueue to the backend.
-We test connection using telnet is successful.

Please help.
Thanks

[juks]

Hi Sihameed,

The following lines say that the data was indeed sent to your backend. But there were no response. So after 35 seconds the client was disconnected due to timeout.

2017-11-12 08:26:20 - info: Upstreaming data for http:::1:57404
2017-11-12 08:26:20 - verbose: [00560800...]

The reason there was no response is more likely your host understands different message or message header syntax. I suggest you check the manual for your host, its log files or any test messages that are known to work.

Thus you can get the syntax difference.

[sihameed]

Hi Igor,

Thank you for the advice.
In case we have to modify the header, how to configure/customize it in SocketQueue?
For your information, our host using 1987 format in ascii.

I check also there is parameter.js, what is the purpose of this file?

[juks]

Sihameed,

Could you please provide message body with header the way your host expects it to be? I mean do you have any test case your host is known to answer?

There is a --lengthHeaderType option with available values 'numeric' or 'hex'. It changes the header format.

You can also use --help so the the list of all options available.

[sihameed]

Hi Igor,

Yes, we have sample from the client system known by our Host.
The client system using JPOS, and have this log when sent request to our host.

<log realm="channel/10.225.16.48:333" at="Tue Nov 14 10:10:36 ICT 2017.920" lifespan="2ms">
  <send>
    <isomsg direction="outgoing">
      <!-- org.jpos.iso.packager.GenericPackager[cfg/isotest/packagers/iso87ascii.xml] -->
      <field id="0" value="0800"/>
      <field id="7" value="111207"/>
      <field id="11" value="263867"/>
      <field id="70" value="001"/>
    </isomsg>
  </send>
</log>
<log realm="channel/10.225.16.48:333" at="Tue Nov 14 10:10:36 ICT 2017.922" lifespan="749493ms">
  <receive>
    <isomsg direction="incoming">
      <!-- org.jpos.iso.packager.GenericPackager[cfg/isotest/packagers/iso87ascii.xml] -->
      <field id="0" value="0810"/>
      <field id="7" value="0000111207"/>
      <field id="11" value="263867"/>
      <field id="39" value="00"/>
      <field id="70" value="001"/>
    </isomsg>
  </receive>
</log>

Also attached those request-response stream (captured from wireshark).
Please help.

jpos-sample-from-host.zip

[juks]

You should use --lengthHeaderType=hex.

In your message the length header is 0037. These is hex length that corresponds to 54 in decimal representation.

Also, the binary mask of the sample provided ('fixed-b-hex') is different then the default format ('binary').

To change it add --overrides=1:fixed-b-hex:8 parameter.

[sihameed]

Hi Igor,

Now looks much better, our host replied the sent message, and SocketQueue can receive the response from host. But still got error and seems like the response not yet parsed well.

I also create new config file - upg (copied from smartVista config).

$ node socketQueue.js --upstreamHost=10.225.16.48 --upstreamPort=333 --listenHttpPort=8080 --echoServerPort=333 --vv --logFile=log.txt --hostConfig upg --lengthHeaderType=hex --overrides=1:fixed-b-hex:8

The response:

2017-11-15 00:01:03 - info: Client http:::1:52396 connected
2017-11-15 00:01:03 - info: Client http:::1:52396 sent data
2017-11-15 00:01:03 - verbose:

http:::1:52396

 [Echo Request]

 Message Type Indicator [0].......................0800
 Bitmap [1].......................................82200000000000000400000000000000
 Transmission Date and Time [7]...................0000111209
 System Trace Audit Number [11]...................436014
 Network Management Information Code [70].........001

2017-11-15 00:01:03 - info: Writing to queue http:::1:52396 [0]
2017-11-15 00:01:03 - info: New queue item 1
2017-11-15 00:01:03 - info: Processing queue [pending 1 / total 1]
2017-11-15 00:01:03 - verbose: Queue keys dump: 1
2017-11-15 00:01:03 - info: Upstreaming data for http:::1:52396
2017-11-15 00:01:03 - verbose: [.7080082...]
2017-11-15 00:01:03 - info: Got data from ISO-host (59b)
2017-11-15 00:01:03 - verbose: [.9081082...]
2017-11-15 00:01:03 - info: Upstream error: ISO host sent data with no client connected! Ignoring...

ISO host says

 [Echo Response]

 Message Type Indicator [0].......................0810
 Bitmap [1].......................................8220000002000000
 Transmission Date and Time [7]...................0400000000
 System Trace Audit Number [11]...................000000
 Response code [39]...............................0 (Successful Transaction)

2017-11-15 00:01:38 - info: Queue notice: http:::1:52396 reached queue timeout
2017-11-15 00:01:38 - info: Dropping the client http:::1:52396
2017-11-15 00:01:38 - info: Client http:::1:52396 gateway timeout

Is there any other parameters need to configured?

[juks]

There seem to be terminal id in the initial message for some reason. SQ knows clients (as all other ISO systems do) by their terminal id.

[juks]

Did you tweak the source? If I run your curl I get the terminal id right:

 Card Acceptor Terminal Identification [41].......00000001

[sihameed]

Yes, i tweak the source by customizing the config file.

Right know i restore back the SQ source, and try to simulate again.
But still have different result from you.

SQ.log
host.log

Please find the logs in attachment.

[juks]

Sihameed, just gave you a wrong hint. Please use

--overrides=1:bitmap-hex:8

This is a proper binary mask format in your case.

[sihameed]

Hi Igor,

The result from our host can parsed well in SQ.
I already define bit-41 in the message, but still get the error, "..no client connected".
Also in bit-41 in the response, SQ parsed to "00000010".

$ curl -H "Content-Type: application/json" -X POST -d '{ "0": "0800", "3": "1", "7": "1112070616", "11": "436017", "24": "1", "41": "1", "70": "001"}' http://127.0.0.1:8080

Please find in attachment the logs from the testing.
SQ-20171117-01.log

Please help...

[juks]

Hi Sihameed.

Your host uses 2 bytes for field 39 instead of 3 which is default. The terminal id is getting shifted one character to the right and turns into 10 instead of 1. So please add an override:

--overrides=1:bitmap-hex:8,39:fixed-n:2

[sihameed]

Hi Igor,

Thank you very much for your help
Following your advice finally we can connect and communicate well to our host.
SQ is awesome 🥇 , and we plan to build gateway using SQ.

If you don't mind, can we have your personal contact? for further more question or any discussion :)

[juks]

Sihameed, personal contact is fine, but let's keep it public here :-)

By the way, what kind of ISO system you work with? As far I can see it is based on JPOS library.

[sihameed]

Ok Igor :-)

Currently i'm work with virtual account payment gateway. Current messaging only support iso8583. Yes you are correct, the system based on JPos library.