[naveen duniwal <mail_naveend@xxxxxxxxx>]

Hi Hansang,

Thanks a lot for your reply .

Regards
Naveen

----- Original Message ----
From: Hansang Bae <hbae@xxxxxxxxxx>
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Sent: Wednesday, 20 August, 2008 12:54:25 AM
Subject: Re: [Wireshark-users] Regarding server's acknowledgement to httpRequest sent

naveen duniwal wrote:
> Hi,
>
> I am working on a project for improving performance, for this I am using
> wireshare to observe time taken by response to come back for a
> particular request.
>
> for some request's , I get server acknowledgment to that request and
> then later i get response for that request ( say it is case 1) , but for
> other request ( different request url ) I get server's acknowledgment
> and response in the same frame ( say it is case 2).
>
> # Case 1
> I am copying wireshark frames in this case.
>
> Request sent
> "788","83.609659","192.168.130.73","192.168.133.101","HTTP","POST
> /FXTrader/Workflow.do?requestURI=dropdownCcy&event=dropdownCcySelected&workflowMessage.ccyPair=USDJPY&workflowMessage.customField=DirectFXTrader_DirectFXTrader_Tradi   
> ngTab0_DealingRateCcPair5&workflowMessage.activetab=DirectFXTrader_TradingTab0&workflowMessage.index=5   
>   
> &workflowMessage.resetCFs=false&workflowMessage.tenor=SPOT&workflowMessage.validate=tenor&workflowMessage.ccyCustomFieldsList=
> HTTP/1.1        (application/x-www-form-urlencoded)"
>
> Server's acknowledgement to my request
> "789","83.709141","192.168.133.101","192.168.130.73","TCP","http > pptp
> [ACK] Seq=86180 Ack=42783 Win=32767 Len=0"
>    This is acknowledgement to the segment in frame in :788
> 
> Response to my request
> "794","84.024469","192.168.133.101","192.168.130.73","HTTP/XML","HTTP/1.1
> 200 OK"
>    <qtPanel><tenors val='SPOT~IMM1~IMM2~1W~2W~1M~2M'/><tenor
> val='SPOT'/> <isBD val='false'/></qtPanel>
>
>
> # Case 2
>
> Request Sent
> "265","20.797080","192.168.130.73","192.168.133.101","HTTP","GET
> /jmsproxy/?cmd=P&uid=524504&c=20&wMs=5000&p=1&aIL=&rL=125&mI=125&mpt=250&lmc=20&QTpt=16&IRpt=0&sts=200&ld=18:216:230&ts=1219051797502&nTQ=11&nTI=3
> HTTP/1.1"
>
> This frame shows that it is Server's acknowledgement to my request as
> well as it contains response, so i am assuming that it is response.
> "266","20.899251","192.168.133.101","192.168.130.73","HTTP","HTTP/1.1
> 200 OK (text/html)"
>    This is acknowledgement to the segment in frame in :265
>
>   
> <script>parent.p([["TQ",1,0,"TQAUDUSD",{"V":"AUD/USD~TRD2cbe1d01ed11bd5263b743ea9d7~USD~4~2~0.0~0.0~0.0~0.0~0.0~0.0~0~20080820~10000~1.0$T1   
> #0.6875#0.6850#2.5E7#3.0E7#A#0#0#$T2#0.6874#0.6851#5.0E7#6.0E7#A#0#0#$T3#0.6873#0.6852#7.5E7#9.0E7#A
>
> So my doubt is why there is a difference between these two cases ?
> Actually my concern is that in case#1 , I am getting response after
> around 400ms but in case#2 that is only 100 ms.I want to modify my
> case#1 to reduce this delay.
>
>
> I can think of following possible differences:
>    1.    The size of the request is higher in case#1 as compared to case#2.
>    2.    response is http/xml in  cases#1
>    3.    content-type is application/x-www-form-urlencoded in Case#1.
>
> I will appreciate any help or suggestiong in this regard.
>
> Thanks in advance.
>
> Regards
> Naveen


Naveen,
In general, it's easier if you email the pcap file (after proper munging
  of data or editcap'ing it to headers only).  You are comparing apples
and oranges.  In case #1, it looks like the ACK (frame #2) is being sent
as a delayed acknowledgment. The 100ms delta is common for (Unix)
delayed ack.  Windows tends to default to 200ms.  So the server gets the
request, the app is munching on the data and and 100ms later, the server
sends just an ACK after 100ms timer goes off.  After 300ms of server
processing delay, the data comes back.  There is another possible
explanation but I can't tell w/o knowing the round trip delay between
the two servers.


In case #2, the delayed ack did it's job.  After waiting for about
100ms, the server sent some data and the ack got piggybacked on the data
packet.

The two requests are different so you need to take that into consideration.

However, in trading applications that use TCP, it's EXTREMELY important
to pay attention to the penalty you can pay for NAGLE and delay-ack
deadlock.

While you cannot force TCP to do anything, you can stack the odds in
your favor.  It's entirely possible that the application sent the data
to the tcp stack, and TCP - obeying Nagle - held on to the data in case
more data was forthcoming from the application.  In fact, the
application timestamp logs may show that it "sent" the data 100 to 200
ms sooner than what you see on the network.  This can happen as the TCP
stack hangs on to the data - obeying Nagle delay - in case he can load
up the packet.

Since you don't have access to FXtrader's socket options, you may have
to tweak the server's tcp stack and hope that the application won't
override the setting at the socket level.  In general, you can ndd the
server to set the no_delay option to turn off Nagle.  There are a lot
of pitfalls, so careful testing monitoring is required.  But that
discussion is beyond the scope of this list.

Google for "nagle delayed ack" and you'll get a lot of hits.



--

Thanks,
Hansang
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-users

---

 Connect with friends all over the world.  Get Yahoo! India Messenger.