Wireshark-users: Re: [Wireshark-users] Retransmits of GIOP
From: Martin Visser <[email protected]>
Date: Tue, 22 Sep 2009 10:47:05 +1000
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

[email protected]

On Tue, Sep 22, 2009 at 1:56 AM, <[email protected]> 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 <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:[email protected]?subject=unsubscribe