question regarding ACK ?

Question

Dear All, I have question regarding how to understand pcap capture by tcpdump and read by wireshark. Below are the listing between 2 ports and 2 ip. If I understand correctly 103.11.134.43 port 9091 receive 1460 byte of data and then reply to the sender that it has acknowledge the data (frame5) to be accepted. If my understanding is correct, then I should have been able to see the byte sent by frame5 in my Java Socket programming when I do socket.read(byte) - rhetorical question. I do get the next frame7 in my Java Socket programming when I do socket.read(byte). -- by right, I should have been able to read frame5 as it has been acknowledged. It seems there is a skipped (instead of reading frame5, it read frame7) -- this happens in non consistent basis - from time to time I get to read frame5 in my socket.read(byte). Why such inconsistency in TCP part? or in Java Socket part?

In my program, I kept getting 0 byte in the server side - while tcpdump and wireshark showed that I actually get 1460 byte - do I get the concept correct?

5 0.027797    202.146.134.42        103.11.134.43         1514   4013 > 9091 [PSH, ACK] Seq=39 Ack=1 Win=16384 Len=1460
Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) Ethernet II, Src: Routerbo_f0:be:b1 (00:0c:42:f0:be:b1), Dst: AsustekC_e8:1a:4d (00:24:8c:e8:1a:4d) Internet Protocol Version 4, Src: 202.146.134.42 (202.146.134.42), Dst: 103.11.134.43 (103.11.134.43) Transmission Control Protocol, Src Port: 4013 (4013), Dst Port: 9091 (9091), Seq: 39, Ack: 1, Len: 1460
Source port: 4013 (4013)
Destination port: 9091 (9091)
[Stream index: 0]
Sequence number: 39    (relative sequence number)
[Next sequence number: 1499    (relative sequence number)]
Acknowledgment number: 1    (relative ack number)
Header length: 20 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 64
[Calculated window size: 16384]
[Window size scaling factor: 256]
Checksum: 0x1f93 [validation disabled]
[SEQ/ACK analysis]
[Bytes in flight: 1498] Data (1460 bytes)

The next sequence of ACK for the byte 1498

6 0.027819    103.11.134.43         202.146.134.42        54     9091 > 4013 [ACK] Seq=1 Ack=1499 Win=64192 Len=0
Frame 6: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: AsustekC_e8:1a:4d (00:24:8c:e8:1a:4d), Dst: Routerbo_f0:be:b1 (00:0c:42:f0:be:b1) Internet Protocol Version 4, Src:
103.11.134.43 (103.11.134.43), Dst: 202.146.134.42 (202.146.134.42) Transmission Control Protocol, Src Port: 9091 (9091), Dst Port: 4013 (4013), Seq: 1, Ack: 1499, Len: 0
Source port: 9091 (9091)
Destination port: 4013 (4013)
[Stream index: 0]
Sequence number: 1    (relative sequence number)
Acknowledgment number: 1499    (relative ack number)
Header length: 20 bytes
Flags: 0x010 (ACK)
Window size value: 1003
[Calculated window size: 64192]
[Window size scaling factor: 64]
Checksum: 0x3e0e [validation disabled]
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 5]
[The RTT to ACK the segment was: 0.000022000 seconds]

The part that socket.read(byte) got to read is the following (frame7 got read instead of frame5)

7 0.027825    202.146.134.42    103.11.134.43         228    4013 > 9091 [PSH, ACK] Seq=1499 Ack=1 Win=16384 Len=174
Frame 7: 228 bytes on wire (1824 bits), 228 bytes captured (1824 bits) Ethernet II, Src: Routerbo_f0:be:b1 (00:0c:42:f0:be:b1), Dst: AsustekC_e8:1a:4d (00:24:8c:e8:1a:4d) Internet Protocol Version 4, Src:
202.146.134.42 (202.146.134.42), Dst: 103.11.134.43 (103.11.134.43) Transmission Control Protocol, Src Port: 4013 (4013), Dst Port: 9091 (9091), Seq: 1499, Ack: 1, Len: 174
Source port: 4013 (4013)
Destination port: 9091 (9091)
[Stream index: 0]
Sequence number: 1499    (relative sequence number)
[Next sequence number: 1673    (relative sequence number)]
Acknowledgment number: 1    (relative ack number)
Header length: 20 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 64
[Calculated window size: 16384]
[Window size scaling factor: 256]
Checksum: 0x4cfa [validation disabled]
[SEQ/ACK analysis]
[Bytes in flight: 174] Data (174 bytes)

Answer 1

Dear All,

It seems I have solve the inconsistency of the problem above by changing the way my Java code do thing. I change the communication protocol.

Original Protocol:

client's side: 1. send order (order for server including file name and file size - form of String) 2. send the actual file 3. receive server's acknowledgement (form of String)

server's side: 1. receive order from client 2. receive the actual file 3. send server's acknowledgement

New Protocol

client's side: 1. send order 2. receive confirmation 3. send actual file 4. receive server's acknowledgement

server's side: 1. receive order 2. send confirmation 3. receive actual file 4. send server's acknowledgement

With new protocol, the file consistently send and if there is a miss, the TCP's protocol re transmit the missing frame.

Even though the problem is somehow solved, I still don't know what cause such inconsistent send/receive file in TCP's socket programming.

Thanks. If anyone can explain the problem above, I would like to thank you in advance.