Author |
Message
|
gfrench |
Posted: Thu Mar 17, 2011 8:12 am Post subject: TCPIPClientReceive Node |
|
|
 Acolyte
Joined: 10 Feb 2002 Posts: 71
|
Hi,
I'm building a flow to send a TCPIP request to an external system and receive the responses. I've built a flow that goes
MQInput -> Compute -> TCPIPClientOutput -> TCPIPClientReceive -> Trace
I've got wireshark running so I can see my request going out to the external system and I can see the correct response coming back, however what ever I try on the TCPIPClientReceive I never seem to pickup the response.
At first I was getting a response down the failure terminal with "timeout waiting for data" although in the exception I could see the last section of the response message so maybe a configuration error. This was probably because the setting "Record detection = Connection Closed" so it would have presumably waited an hour for my IP connection to close by the server after no activity except for the 30 sec timeout. But why did it go down the failure node and not the timeout?
Having read some stuff in this forum I then set the TCPIPClientReceive node to "RecordDetection = Parsed Record Sequence" because the record coming back is a blob with the first bytes a length of the message and I've created a simple MRM message for it. However now I just get "Could not parse the bitstream into a sequence of records because no bytes where parsed for the current record"
Is this because its getting a zero record ACK or something before the data comes through? I see on wireshark
My Flow --- hello ----> external system
My Flow <-- ACK ----- external system
My Flow <--- greeting ----- external system
My Flow --- ACK ----> external system
Any thoughts or examples any one has working would be great...
and something I don't get... why is their connection details on the TCPIPClientReceive node. If I'm sending to port 7878 at externalHost should they read localhost:7878 or externalHost:7878. The samples don't make this clear.
I guess I should add 6.1.0.8 on windows at the moment. |
|
Back to top |
|
 |
harish_td |
Posted: Sun Mar 20, 2011 4:57 am Post subject: Re: TCPIPClientReceive Node |
|
|
Master
Joined: 13 Feb 2006 Posts: 236
|
gfrench wrote: |
and something I don't get... why is their connection details on the TCPIPClientReceive node. If I'm sending to port 7878 at externalHost should they read localhost:7878 or externalHost:7878. The samples don't make this clear. |
We have used the following settings on our Message Flow and it works great.
TCPIPClientOutput pointed to externalHost:7878 and
[Advanced] Input Stream Modification set to "Reserve input stream then release at end of flow"
TCPIPClientReceive pointed to externalHost:7878 and parse timing set to Complete for a Parsed Record Sequence record detection.
When you use a TCPIP Client software (Not a Message Broker flow) and send the expected message to the TCPIP Server, do you see any responses coming back from the server?
If Yes, Can the data be successfully parsed by your length encoded message set?
I have had more trouble with the server than the message broker flow itself. |
|
Back to top |
|
 |
gfrench |
Posted: Sun Mar 20, 2011 1:29 pm Post subject: |
|
|
 Acolyte
Joined: 10 Feb 2002 Posts: 71
|
I'll test the setting tomorrow, but interested on your comment about testing the server with software. I always do that before developing soap or http flows (using soapUI) but hadn't thought to download client ip testing software.
Just had a quick look on CNET and found 'Simple TCP Client'. There seems to be a few others. Is there one that you have used and would recommend.
Cheers
Graham |
|
Back to top |
|
 |
harish_td |
Posted: Sun Mar 20, 2011 5:37 pm Post subject: |
|
|
Master
Joined: 13 Feb 2006 Posts: 236
|
Quote: |
Is there one that you have used and would recommend. |
I personally like the look-and-feel and the features offered by TCP IP Test Server.
Since it is free software, the standard security disclaimers would apply, lest you infect your PC with a virus/malware that causes far more pain than a message flow that does not work |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Mar 21, 2011 2:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
There is a TCP/IP Monitor view supplied with Toolkit - "Show View"->Other->Debug->TCP/IP Monitor.
It's at least a quick and dirty test tool, and can be useful in local conditions. |
|
Back to top |
|
 |
gfrench |
Posted: Mon Mar 21, 2011 5:16 am Post subject: |
|
|
 Acolyte
Joined: 10 Feb 2002 Posts: 71
|
OK, problem sorted. It was a combination of configuration, my message set and then big endian. Getting the data correctly now.
Thanks for all the help. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Mar 21, 2011 5:39 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
gfrench |
Posted: Mon Mar 21, 2011 9:01 am Post subject: |
|
|
 Acolyte
Joined: 10 Feb 2002 Posts: 71
|
I'm progressing well! One issue I'm looking at is that the server sends out a greeting at first connection, so if I do a logon I seem to need a flow that looks like
TCPIPClientOutput(Login) -> TCPClientReceive(Greeting) -> TCPClientRecieve(Response)
When I send a normal request
TCPIPClientOutput(Request) -> TCPIPClientReceive(Response)
But if the connection is lost and I send a request I again need an extra TCPIPClientReceive node to catch the Greeting since new connection, then in the second receive I can see the response is a authorisation failure and I need to login.
I guess I could put a loop into the code and when greeting loop back to TCPIPClientReceive node, but I feel there should be some better way to marry the send and the receive. Any thoughts? Help gratefully received.
Thanks
Graham |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Mar 21, 2011 9:05 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
I would have one flow that does both. You could have an exception processing path in your message flow that handles the event that the response is returned not matching the normal case (ie. when it is "greeting" or something else), and if it is simply a greeting issue, reroute back into the main part of your flow. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
|