TCP/IP settings for Web Service Client?

[tgoepferd]

Hello,

I have an application that launches a SOAP request to a .NET web service. My applcation runs on JBoss 4.0.4 on Redhat vLinux 2.6.9-42.ELsmp (i386) with Java 1.5.0_07_b3

The SOAP messages that I send are being broken into two packets. Using TCPDUMP, I see that the two packets are being sent within a couple milliseconds. However, in a few cases, the second packet is not sent for 2 seconds after the first packet is sent. Since our application requires low latency, a 2 second wait just to get the packet on the wire is too long.

Does anyone know of any possible causes for this?
Does anyone know if my application can set any flags or config settings to minipulate the TCP/IP stack behavior?

Our client is so far removed ( which I am very happy about) from the TCP/IP implementation, that I assume we are at the mercy of the OS and how JBoss interacts with it. Never-the-less, this is an important application for us and any help would be appreciated.

Thanks,
Todd Goepferd

[zurchman]

Using TCPDUMP, I see that the two packets are being sent within a couple milliseconds.

Do the tcpdump timestamps show a two second latency between packets?

[tgoepferd]

Here is the TCPDump output when it is working correctly. There are many examples of this:

Initial 3-way handshake
SYN
18:01:30.769521 IP alpha.abc.com.58548 > 163.130.1.201.http: S 4126902008:4126902008(0) win 5840 <mss 1460,sackOK,timestamp 3028392681 0,nop,wscale 2>
SYN-ACK
18:01:30.918689 IP 163.130.1.201.http > alpha.abc.com.58548: S 63388846:63388846(0) ack 4126902009 win 8760 <mss 1460,eol>
ACK
18:01:30.918721 IP alpha.abc.com.com.58548 > 163.130.1.201.http: . ack 1 win 5840

POST - First half of message
18:01:30.919050 IP alpha.abc.com.58548 > 163.130.1.201.http: . 1:1461(1460) ack 1 win 5840
Continuation - 2nd Half of Message with push flag
18:01:30.919074 IP alpha.abc.com > 163.130.1.201.http: P 1461:1779(318) ack 1 win 5840

TCP level ACK
18:01:31.101948 IP 163.130.1.201.http > alpha.abc.com.58548: . ack 1779 win 64240
ACK Resent????, (Final Flag set)
18:01:31.387309 IP 163.130.1.201.http > alpha.abc.com.58548: F 204:204(0) ack 1779 win 64240
handshake... we got your ack.
18:01:31.387342 IP alpha.abc.com.58548 > 163.130.1.201.http: . ack 1 win 5840


202 Accepted - (Final Flag set)
18:01:34.428663 IP 163.130.1.201.http >alpha.abc.com.58548: FP 1:204(203) ack 1779 win 64240
Got your 202
18:01:34.469118 IP alpha.abc.com.58548 > 163.130.1.201.http: . ack 205 win 6432

Bye - Closing Connection
18:02:53.064082 IP alpha.abc.com.58548 > 163.130.1.201.http: F 1779:1779(0) ack 205 win 6432
Bye - Ack connection closing.
18:02:53.211680 IP 113.130.1.201.http > alpha.abc.com.58548: . ack 1780 win 64240

Here is an example of one where the 2nd half of the message is delayed by 5 seconds:

Initial 3 way handshake... SYN was resent after 3 seconds.
18:00:44.099506 IP alpha.abc.com.58525 > 163.130.1.201.http: S 4080391120:4080391120(0) win 5840 <mss 1460,sackOK,timestamp 3028345997 0,nop,wscale 2>
18:00:47.099218 IP alpha.abc.com.58525 > 163.130.1.201.http: S 4080391120:4080391120(0) win 5840 <mss 1460,sackOK,timestamp 3028348998 0,nop,wscale 2>
18:00:47.286140 IP 163.130.1.201.http > alpha.abc.com.58525: S 4104645:4104645(0) ack 4080391121 win 8760 <mss 1460,eol>
18:00:47.286188 IP alpha.abc.com.58525 > 163.130.1.201.http: . ack 1 win 5840


POST - First Half of Message
18:00:47.286588 IP alpha.abc.com.58525 > 163.130.1.201.http: . 1:1461(1460) ack 1 win 5840
2nd Half of message
18:00:52.286766 IP alpha.abc.com.58525 > 163.130.1.201.http: FP 1461:1774(313) ack 1 win 5840
18:00:52.432341 IP 163.130.1.201.http > alpha.abc.com.58525: . ack 1775 win 63927
202 Accepted
18:00:52.433752 IP 163.130.1.201.http > alpha.abc.com.58525: P 1:204(203) ack 1775 win 63927
Reset COnnection
18:00:52.433780 IP alpha.abc.com.58525 > 163.130.1.201.http: R 4080392895:4080392895(0) win 0
AcK with /Final
18:00:52.434478 IP 163.130.1.201.http > alpha.abc.com.58525: F 204:204(0) ack 1775 win 63927
Reset Connection
18:00:52.434501 IP alpha.abc.com.58525 > 163.130.1.201.http: R 4080392895:4080392895(0) win 0

NOTE: I am no TCP guru.... so I am not sure if my comments between the messages are accurate. However, from the message body, I could tell which packets contianed the SOAP messages.