| Author |
Message
|
| amith kashyap |
 Posted: Tue Nov 22, 2016 1:28 am Post subject: Two Requests in single TCP/IP Stream - WMB TCPIP Client node |
 |
|
Newbie
Joined: 02 Sep 2016
Posts: 7
|
We are sending TCP request to back end using WMB TCP/IP client. It is working fine when the load is less. When load test was performed for 30 seconds using 5 threads, out of 719, there was no response for 6 requests. When we check the logs generated by iptrace, we could see that two requests are going as single stream(for all 6 requests which were not responded). ie, if my message length is 712 bytes, we can see 1424 bytes transferred in single stream and there was no response for second request. (second 712 bytes).
Could you please let me know why 2 request are sent in the same stream. |
|
| Back to top |
|
 |
| timber |
| Posted: Tue Nov 22, 2016 4:19 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Have you checked all of the properties on the TCPIPClientOutput node? Some of those properties control whether the stream is closed/reused after sending, if I recall correctly. |
|
| Back to top |
|
|
| amith kashyap |
| Posted: Tue Nov 22, 2016 7:13 pm Post subject: |
|
|
Newbie
Joined: 02 Sep 2016
Posts: 7
|
We are using default properties to reuse the stream.
P.S - We are making call to a java class for encryption before passing the request to TCPIPClinet output node. Is this causing any issue? |
|
| Back to top |
|
|
| timber |
| Posted: Wed Nov 23, 2016 2:47 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| We are making call to a java class for encryption before passing the request to TCPIPClinet output node. Is this causing any issue? |
Why should it? If the encryption is only operating on the data in the message tree then I don't see any way that it could affect the operation of the output node.
More diagnosis required, I think. |
|
| Back to top |
|
|
| amith kashyap |
| Posted: Wed Nov 23, 2016 11:56 pm Post subject: |
|
|
Newbie
Joined: 02 Sep 2016
Posts: 7
|
We are passing fixed-length request of 712 length (the first 9 bytes are the length of the message itself), to destination in bulk mode.(750 reqs in 30 seconds)
"TCP","778","","SrcPort → DestPort [PSH, ACK] Seq=4985 Ack=7729 Win=32683 Len=712 TSval=1491281783 TSecr=956083500"
"TCP","1490","","SrcPort → DestPort [PSH, ACK] Seq=2849 Ack=3865 Win=32683 Len=1424 TSval=1491281783 TSecr=956083500"
In the above two lines from iptrace, there are two packets passed from source to destination.
The first packet is of length 712, which is the length of my fixed-length request and getting proper response.
The second packet is of length of 1424, I can see two requests if I read the stream. i.e., two requests combined and sent in single packet.
In the two requests, only the first message (First 712 bytes) was responded. There was no response for the second 712 bytes.
My Doubt is:
The packet size doesn't matter? I mean TCP can make packets of any size? If so, is there any option to make TCPClientOut to send single message at a time?
Is the destination is not capable of reading the second message? They are reading only the first 712 as the length is mentioned in the message itself. |
|
| Back to top |
|
|
| timber |
| Posted: Thu Nov 24, 2016 3:12 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
First, let me state clearly that I'm not a TCP/IP guru.
I do know that TCP/IP is a stream-oriented protocol, and the receiver usually needs to be aware of that.
I'm pretty sure that the TCP/IP output node cannot control how the TCP/IP stack splits the stream into packets. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Nov 24, 2016 9:29 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| amith kashyap wrote: |
We are passing fixed-length request of 712 length (the first 9 bytes are the length of the message itself), to destination in bulk mode.(750 reqs in 30 seconds)
|
Whenever I have used the TCPIP nodes that use what I call 'run length encoded' transmission as oppoased to delimited transmission I send TWO messages to the receiver.
The first message was fixed length, usually 5 bytes long and contained a BLOB that contained the Lenght as an integer of the message to follow.
The second message contained the data of the length specified.
does the receiver ack the first packet or does it NAK it? You have shown only one side of the story.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| amith kashyap |
| Posted: Thu Nov 24, 2016 5:30 pm Post subject: |
|
|
Newbie
Joined: 02 Sep 2016
Posts: 7
|
| Quote: |
| I'm pretty sure that the TCP/IP output node cannot control how the TCP/IP stack splits the stream into packets |
Thank you so much for your time and response.
| Quote: |
| The first message was fixed length, usually 5 bytes long and contained a BLOB that contained the length as an integer of the message to follow. |
The same idea is applied here too, but in a single message, the first 9 bytes are integer which will have the length of the message followed.
In the 712 bytes sent to the server, the first 9 bytes are length which will have a value of 000000703, to intimate that the server application should read next 703 bytes as single request. That is what was agreed and I don't see any problem until I send requests in bulk mode.
The problem here is, we can see "000000703.......(703 bytes)000000703.....(703 bytes)" in single TCP packet. The first message was responded but the second one was not responded. |
|
| Back to top |
|
|
|
|
