jrb@amadeus.WR.TEK.COM (Jim Binkley) (09/28/89)
A couple of questions about TCP implementations. I noticed that running two rsh commands in a row: rsh NONSUN date; rsh NONSUN date; from a Sun to a NONSUN BSD system (say Ultrix, or 4.3 BSD or you name it) was taking somewhere between 5-8 seconds between rsh the first and rsh the second. This seemed overly long. Then I discovered "etherfind" and captured the following dialogue: (etherfind -t -v -proto tcp -between bambi godzilla; this gives us a verbose tcp conversation with a timestamp. I edited out everything between the initial SYN/ACK and final FINs messages.) RSH #1. 0.00 TCP from bambi.1020 to godzilla.shell seq BA18A00, SYN, window 4096, 0.02 TCP from godzilla.shell to bambi.1020 seq 706141, ack BA18A01, SYN, window 4096, 0.02 TCP from bambi.1020 to godzilla.shell seq BA18A01, ack 706142, window 4096, 0.02 TCP from bambi.1020 to godzilla.shell seq BA18A01, ack 706142, window 4096, 5 bytes data 0.20 TCP from godzilla.shell to bambi.1020 seq 706142, ack BA18A06, window 4091, 0.22 TCP from godzilla.1020 to bambi.1019 seq 706181, SYN, window 4096, 0.22 TCP from bambi.1019 to godzilla.1020 seq BA37E00, ack 706182, SYN, window 4096, 0.22 TCP from godzilla.1020 to bambi.1019 seq 706182, ack BA37E01, window 4096, 0.64 TCP from godzilla.shell to bambi.1020 seq 706156, ack BA18A13, FIN, window 4096, 0.64 TCP from bambi.1020 to godzilla.shell seq BA18A13, ack 706157, window 4078, 0.64 TCP from godzilla.1020 to bambi.1019 seq 706182, ack BA37E01, FIN, window 4096, 0.64 TCP from bambi.1019 to godzilla.1020 seq BA37E01, ack 706183, window 4096, 0.70 TCP from bambi.1019 to godzilla.1020 seq BA37E01, ack 706183, FIN, window 4096, 0.70 TCP from bambi.1020 to godzilla.shell seq BA18A13, ack 706157, FIN, window 4096, 0.72 TCP from godzilla.1020 to bambi.1019 seq 706183, ack BA37E02, window 4096, 0.72 TCP from godzilla.shell to bambi.1020 seq 706157, ack BA18A14, window 4096, RSH #2 1.44 TCP from bambi.1020 to godzilla.shell seq BA66C00, SYN, window 4096, 1.46 TCP from godzilla.shell to bambi.1020 seq 706157, ack BA18A14, window 4096, 1.46 TCP from bambi.1020 to godzilla.shell seq BA18A14, RESET, window 4096, 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C00, SYN, window 4096, 7.08 TCP from godzilla.shell to bambi.1020 seq 706541, ack BA66C01, SYN, window 4096, 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C01, ack 706542, window 4096, 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C01, ack 706542, window 4096, 5 bytes data 7.20 TCP from godzilla.shell to bambi.1020 seq 706542, ack BA66C06, window 4091, 7.28 TCP from godzilla.1021 to bambi.1019 seq 706581, SYN, window 4096, 7.28 TCP from bambi.1019 to godzilla.1021 seq BB31E00, ack 706582, SYN, window 4096, 7.28 TCP from godzilla.1021 to bambi.1019 seq 706582, ack BB31E01, window 4096, 7.56 TCP from godzilla.shell to bambi.1020 seq 706556, ack BA66C13, FIN, window 4096, 7.56 TCP from bambi.1020 to godzilla.shell seq BA66C13, ack 706557, window 4078, 7.58 TCP from godzilla.1021 to bambi.1019 seq 706582, ack BB31E01, FIN, window 4096, 7.58 TCP from bambi.1019 to godzilla.1021 seq BB31E01, ack 706583, window 4096, 7.60 TCP from bambi.1019 to godzilla.1021 seq BB31E01, ack 706583, FIN, window 4096, 7.60 TCP from bambi.1020 to godzilla.shell seq BA66C13, ack 706557, FIN, window 4096, 7.60 TCP from godzilla.1021 to bambi.1019 seq 706583, ack BB31E02, window 4096, 7.60 TCP from godzilla.shell to bambi.1020 seq 706557, ack BA66C14, window 4096, Bambi was the sun machine. Godzilla was the non-sun machine. What is curious to me is that on the second TCP invocation, the non-sun "Godzilla" sends back an ack on the previous window with a non-advanced sequence number. Should it not send back a reset? What is the proper behaviour here? The other question is what mechanism in the Unix src code is governing the 5+ second wait after the Sun sends the RESET. Why does it wait so long? I turned the conversation around and found that the results were similar but the RESET wait from the non-sun machine was less than 1 second. Jim Binkley Tektronix, Portland, Oregon jrb@amadeus.wr.tek.com James Binkley jrb@amadeus.wr.tek.com