This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

discrepancy between async and sync in wireshark

0

Hi Team,

Do we can decide that a transaction is using async / sync by wireshark ? which the button / tools in wireshark we can see sync / async ?

Thanks Wilis

asked 15 Jul '13, 19:17

Wilis's gravatar image

Wilis
11223
accept rate: 0%

What do you mean by "synchronous" and "asynchronous" here?

(15 Jul '13, 20:24) Guy Harris ♦♦

Hi Harris,

Sync is the second transaction will be sent once the first transaction finished. Async is will be sent transaction regardless the first transaction finished.

Thanks Wilis

(15 Jul '13, 20:33) Wilis

2 Answers:

0

OK, so if there is only ONE client thread involved with a client <-> server endpoint pair (i.e., on any given client machine, you don't have multiple client processes or threads sending transactions to a given server between the same endpoints), then you can manually determine whether the client thread is running synchronously or asynchronously by looking at the traces; there are no built-in tools in Wireshark where you can just "push a button" and get the answer. You might be able to write, for example, a Lua script for your particular protocol that could do that; figuring out how to do that is up to you.

If there's more than one client thread using the endpoint pair, each thread might be acting synchronously, but the client as a whole might act asynchronously, with thread 1 sending a transaction and thread 2 sending another transaction before the reply from transaction 1 is sent back. Unless there's some way to identify which thread sent or received a particular packet, you can't distinguish between threads acting asynchronously and multiple synchronous threads just by looking at a network trace.

If Wireshark is not running on the client machine, then, unless the protocol has some field in it that lets you identify which thread sent a request or to which thread a reply is being sent, there's no way to determine which thread sent or received a particular packet.

Even if it is running on the client machine, Wireshark doesn't currently provide a way to associate packets with processes (other than the very limited mechanism supported by OS X Mountain Lion's tcpdump, but not supported by Wireshark, which only associates process names with some outgoing packets by attaching pcap-ng comments to them), and, even if it did, that wouldn't let you identify particular threads within a process.

answered 15 Jul '13, 21:06

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

0

I assume this question is a follow-up to your other question: http://ask.wireshark.org/questions/22843/discrepancy-between-psh-and-without-psh

You already asked for a way to detect sync/async requests in Wireshark.

Cite: So we need to increase the performance of our customers/ client servers. Can we know whether the client is using synchronous method or asynchronous method by wireshark ?

As your communication is HTTP the requests can be asynchronous or synchronous only within the logic of your software, as there is no such concept in the HTTP protocol.

The communication of your client uses one TCP connection to send several HTTP/1.1 GET requests (at least according the the information you provided in your other question).

As per definition of HTTP the client must wait for the answer before it is allowed to send another request (unless you use HTTP/1.1 pipelining).

The structure of your communication could be called serial/sequential (request, response, request, response, etc.). If you want to speed up the communication you need some form of parallel communication, meaning the client must open several parallel TCP connections and send different requests through these TCP connections. If the order of the client requests is not important, you don't have to synchronize these requests within the application and then we are talking about something that could by called asynchronous communication within your application.

Maybe parallel communication will solve the problem you faced in the other question. However, please see also my analysis in that question for the (real) cause of the performance problems. I think it would be easier to analyze the problem of delayed response within the server, instead of re-writing the client to use parallel communication.

Do we can decide that a transaction is using async / sync by wireshark ? which the button / tools in wireshark we can see sync / async ?

UPDATE

As @Guy Harris already said: There is no one-click solution in Wireshark to detect 'asynchronous' (I'd say parallel) communication in your scenario. However, you can figure out pretty easily if a client opens several parallel connections to a server by running the following command on the capture file.

tshark -nr input.pcap -R "http.request and ip.addr eq x.x.x.x and ip.addr eq y.y.y.y" -T fields -e tcp.stream

Please replace:

  • x.x.x.x with the client IP address
  • y.y.y.y with the server IP address

Then look at the tcp.stream numbers (output of tshark). Is there only one number, do the numbers increase constantly or are the numbers intermixed?

  • only one number: the client opened only one connection to the server
  • numbers increase: the client opened one connection after the other (serial/sequential communication)
  • intermixed numbers: the client opened several connections to the server in parallel

Regards
Kurt

answered 16 Jul '13, 02:31

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 16 Jul '13, 05:38

Hi Kurt,

Thanks for your explanation, we will try your suggestion later. In the other hand, here are the results of snoop from client A and client B :

Client A :

No.,"Time","Source","Destination","Protocol","Length","Info"
1,"0.000000","10.251.151.32","10.2.230.48","TCP","66","64484 > http [SYN] Seq=0 Win=49640 Len=0 MSS=1460 WS=1 SACK_PERM=1"
2,"0.000957","10.2.230.48","10.251.151.32","TCP","66","http > 64484 [SYN, ACK] Seq=0 Ack=1 Win=49640 Len=0 MSS=1460 WS=1 SACK_PERM=1"
3,"0.001024","10.251.151.32","10.2.230.48","TCP","54","64484 > http [ACK] Seq=1 Ack=1 Win=49640 Len=0"
4,"0.001492","10.251.151.32","10.2.230.48","HTTP","407","GET /notification?ST.MSISDN=6285350245505&ST.IMSI=510105052245505&ST.IMEI=35325904007861&ST.MSCID=12080012042618010686&ST.VENDOR=Samsung&ST.MODEL=I5500 HTTP/1.1 "
5,"0.002502","10.2.230.48","10.251.151.32","TCP","60","http > 64484 [ACK] Seq=1 Ack=354 Win=49640 Len=0"
6,"0.002641","10.2.230.48","10.251.151.32","TCP","408","[TCP segment of a reassembled PDU]"
7,"0.002684","10.251.151.32","10.2.230.48","TCP","54","64484 > http [ACK] Seq=354 Ack=355 Win=49640 Len=0"
8,"0.002878","10.251.151.32","10.2.230.48","TCP","54","64484 > http [FIN, ACK] Seq=354 Ack=355 Win=49640 Len=0"
9,"0.003148","10.251.151.32","10.2.230.48","HTTP","408","GET /notification/?ST.MSISDN=6285350245505&ST.IMSI=510105052245505&ST.IMEI=35325904007861&ST.MSCID=12080012042618010686&ST.VENDOR=Samsung&ST.MODEL=I5500 HTTP/1.1 "
10,"0.003653","10.2.230.48","10.251.151.32","HTTP","238","HTTP/1.1 301 Moved Permanently  (text/html)"
11,"0.003692","10.251.151.32","10.2.230.48","TCP","54","64484 > http [RST] Seq=355 Win=49640 Len=0"
12,"0.003715","10.2.230.48","10.251.151.32","TCP","60","http > 64484 [ACK] Seq=539 Ack=355 Win=49640 Len=0"
13,"0.003764","10.2.230.48","10.251.151.32","TCP","60","http > 64484 [FIN, ACK] Seq=539 Ack=355 Win=49640 Len=0"
14,"0.003777","10.251.151.32","10.2.230.48","TCP","54","64484 > http [RST] Seq=355 Win=0 Len=0"
15,"0.003826","10.251.151.32","10.2.230.48","TCP","54","64484 > http [RST] Seq=355 Win=0 Len=0"
16,"0.004355","10.2.230.48","10.251.151.32","HTTP","267","HTTP/1.1 200 OK "
17,"0.007685","10.251.151.32","10.2.230.48","TCP","66","64485 > http [SYN] Seq=0 Win=49640 Len=0 MSS=1460 WS=1 SACK_PERM=1"
18,"0.008641","10.2.230.48","10.251.151.32","TCP","66","http > 64485 [SYN, ACK] Seq=0 Ack=1 Win=49640 Len=0 MSS=1460 WS=1 SACK_PERM=1"
19,"0.008700","10.251.151.32","10.2.230.48","TCP","54","64485 > http [ACK] Seq=1 Ack=1 Win=49640 Len=0"
20,"0.009090","10.251.151.32","10.2.230.48","HTTP","403","GET /notification?ST.MSISDN=6281382305449&ST.IMSI=510108233303691&ST.IMEI=35464205721261&ST.MSCID=12080012042618010743&ST.VENDOR=Nokia&ST.MODEL=100 HTTP/1.1 "
21,"0.009993","10.2.230.48","10.251.151.32","TCP","60","http > 64485 [ACK] Seq=1 Ack=350 Win=49640 Len=0"
22,"0.010160","10.2.230.48","10.251.151.32","TCP","404","[TCP segment of a reassembled PDU]"
23,"0.010201","10.251.151.32","10.2.230.48","TCP","54","64485 > http [ACK] Seq=350 Ack=351 Win=49640 Len=0"
24,"0.010381","10.251.151.32","10.2.230.48","TCP","54","64485 > http [FIN, ACK] Seq=350 Ack=351 Win=49640 Len=0"
25,"0.010624","10.251.151.32","10.2.230.48","HTTP","404","GET /notification/?ST.MSISDN=6281382305449&ST.IMSI=510108233303691&ST.IMEI=35464205721261&ST.MSCID=12080012042618010743&ST.VENDOR=Nokia&ST.MODEL=100 HTTP/1.1 "
26,"0.011176","10.2.230.48","10.251.151.32","HTTP","238","HTTP/1.1 301 Moved Permanently  (text/html)"
27,"0.011217","10.251.151.32","10.2.230.48","TCP","54","64485 > http [RST] Seq=351 Win=49640 Len=0"
28,"0.011231","10.2.230.48","10.251.151.32","TCP","60","http > 64485 [ACK] Seq=535 Ack=351 Win=49640 Len=0"
29,"0.011271","10.251.151.32","10.2.230.48","TCP","54","64485 > http [RST] Seq=351 Win=0 Len=0"
30,"0.011288","10.2.230.48","10.251.151.32","TCP","60","http > 64485 [FIN, ACK] Seq=535 Ack=351 Win=49640 Len=0"

CLIENT B :

No.,"Time","Source","Destination","Protocol","Length","Info"
1,"0.000000","10.251.151.32","10.251.228.15","TCP","389","46923 > irdmi [PSH, ACK] Seq=1 Ack=1 Win=49640 Len=335"
2,"0.001783","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46923 [ACK] Seq=1 Ack=336 Win=33 Len=0"
3,"0.011218","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46913 [PSH, ACK] Seq=1 Ack=1 Win=33 Len=76"
4,"0.012526","10.251.151.32","10.251.228.15","TCP","396","46913 > irdmi [PSH, ACK] Seq=1 Ack=77 Win=49640 Len=342"
5,"0.014387","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46913 [ACK] Seq=77 Ack=343 Win=33 Len=0"
6,"0.185122","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46912 [PSH, ACK] Seq=1 Ack=1 Win=65 Len=76"
7,"0.186193","10.251.151.32","10.251.228.15","TCP","399","46912 > irdmi [PSH, ACK] Seq=1 Ack=77 Win=49640 Len=345"
8,"0.187918","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46912 [ACK] Seq=77 Ack=346 Win=65 Len=0"
9,"0.239474","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46913 [PSH, ACK] Seq=77 Ack=343 Win=33 Len=76"
10,"0.240768","10.251.151.32","10.251.228.15","TCP","398","46913 > irdmi [PSH, ACK] Seq=343 Ack=153 Win=49640 Len=344"
11,"0.242604","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46913 [ACK] Seq=153 Ack=687 Win=33 Len=0"
12,"0.259261","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46923 [PSH, ACK] Seq=1 Ack=336 Win=33 Len=76"
13,"0.260272","10.251.151.32","10.251.228.15","TCP","398","46923 > irdmi [PSH, ACK] Seq=336 Ack=77 Win=49640 Len=344"
14,"0.262112","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46923 [ACK] Seq=77 Ack=680 Win=33 Len=0"
15,"0.409021","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46912 [PSH, ACK] Seq=77 Ack=346 Win=65 Len=76"
16,"0.410261","10.251.151.32","10.251.228.15","TCP","398","46912 > irdmi [PSH, ACK] Seq=346 Ack=153 Win=49640 Len=344"
17,"0.411954","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46912 [ACK] Seq=153 Ack=690 Win=65 Len=0"
18,"0.471328","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46913 [PSH, ACK] Seq=153 Ack=687 Win=33 Len=76"
19,"0.472568","10.251.151.32","10.251.228.15","TCP","402","46913 > irdmi [PSH, ACK] Seq=687 Ack=229 Win=49640 Len=348"
20,"0.474414","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46913 [ACK] Seq=229 Ack=1035 Win=33 Len=0"
21,"0.617176","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46912 [PSH, ACK] Seq=153 Ack=690 Win=65 Len=76"
22,"0.618329","10.251.151.32","10.251.228.15","TCP","407","46912 > irdmi [PSH, ACK] Seq=690 Ack=229 Win=49640 Len=353"
23,"0.620088","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46912 [ACK] Seq=229 Ack=1043 Win=65 Len=0"
24,"0.631317","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46913 [PSH, ACK] Seq=229 Ack=1035 Win=33 Len=76"
25,"0.739216","10.251.228.15","10.251.151.32","TCP","130","irdmi > 46923 [PSH, ACK] Seq=77 Ack=680 Win=33 Len=76"
26,"0.740527","10.251.151.32","10.251.228.15","TCP","399","46923 > irdmi [PSH, ACK] Seq=680 Ack=153 Win=49640 Len=345"
27,"0.742451","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46923 [ACK] Seq=153 Ack=1025 Win=33 Len=0"
28,"0.744909","10.251.151.32","10.251.228.15","TCP","54","46913 > irdmi [ACK] Seq=1035 Ack=305 Win=49640 Len=0"
29,"0.817865","10.251.151.32","10.251.228.15","TCP","398","46913 > irdmi [PSH, ACK] Seq=1035 Ack=305 Win=49640 Len=344"
30,"0.819795","10.251.228.15","10.251.151.32","TCP","60","irdmi > 46913 [ACK] Seq=305 Ack=1379 Win=33 Len=0"

As i know that client A is using Async, and client B is using Sync. Client A using Async because i see that the structure of transaction is not irregullar. Client B using Sync becuse i see that the structure of transaction is regullar.

Correct me if i am wrong.

Thanks Wilis

(16 Jul '13, 20:08) Wilis

As i know that client A is using Async, and client B is using Sync. Client A using Async because i see that the structure of transaction is not irregullar. Client B using Sync becuse i see that the structure of transaction is regullar.

I explained the difference between sync/async and serial/sequential/parallel above.

The communication of both A and B is using several TCP connections. However, Client A opens one connection after the other (serial/sequential), while Client B uses several connections in parallel.

The output of the tshark command (see my answer) would be:

Client A:

64484
64485

Client B:

46923
46913
46912
46913
46923
etc.

So, to me it looks like Client B uses parallel communication, while Client A uses serial/sequential communication.

If you still like the terms sync/async, I would say, that the application on Client B seems to be working in async mode, as several requests are being sent, before the answer for other requests has arrived. Client A seems to be working in sync mode, as it sends a request, waits for an answer, sends a request, waits for an answer, etc.

(16 Jul '13, 23:31) Kurt Knochner ♦