You are probably better off posting .pcap file to give a better answer. However, at a guess packet 2 was probably sent after a short (maybe a second or two)delay. This is because the sender's TCP retransmission timer has gone off but hasn't had an ACK from the receiver. Packet 3 probably means that the receiver was bit slow, but it did ACK packet 1. However because the receiver also received packet 2 it assumes that the sender has not seen it's ACK, and so it needs to ACK again.
I think you will find this is all quite normal behaviour. You will sometimes see superfluous (or duplicate ACKs) that are the result of timers not quite being able to adapt quick enough to changing host or network conditions. As long as they do reach stead-state, there is no protocol issue here.
Regards, Martin
MartinVisser99@xxxxxxxxx
On Tue, Sep 22, 2009 at 1:56 AM,
<rkruz@xxxxxxx> wrote:
When following a GIOP conversation with WS, I often see several retransmits of the identical GIOP packet in a row.
For example below:
Retrans is followed by a GIOP ACK to the 1st (original packet).
Then comes a TCP ACK to the 2nd packet.
1 GIOP#1 1st
2 (Retrans) GIOP#1 2nd
3 GIOP ACK to GIOP#1 1st
4 TCP ACK to GIOP#1 2nd
After the GIOP ACK to the original packet, there appears to be a TCP ACK to each GIOP retrans.
Is this how it should be.? Are the retrans packets then just dropped by the application? How does the network differentiate between a GIOP ACK and a TCP ACK?
Any insight appreciated.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
