Return-Path: william@bourbon.usc.edu Delivery-Date: Tue Oct 21 23:08:37 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3 Received: from bourbon.usc.edu (bourbon.usc.edu [128.125.9.75]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m9M68bwV001715 for ; Tue, 21 Oct 2008 23:08:37 -0700 Received: from bourbon.usc.edu (localhost.localdomain [127.0.0.1]) by bourbon.usc.edu (8.14.2/8.14.1) with ESMTP id m9M6IC07001204 for ; Tue, 21 Oct 2008 23:18:12 -0700 Message-Id: <200810220618.m9M6IC07001204@bourbon.usc.edu> To: cs551@merlot.usc.edu Subject: Re: Lecture13: Slide 14 Date: Tue, 21 Oct 2008 23:18:12 -0700 From: Bill Cheng Someone wrote: > In the 5th step, the 'A' side sends an ACK only in the message. I think > there shouldn't be a new SEQ for just an ACK message. > > Shouldn't the SEQ remain at 100 as it has already sent all its data ? Hmm... I would agree with you. This page is copied from RFC 1337 and that's how they had it in RFC 1337. In RFC 1337, it mentioned that the first 5 steps were copied from RFC 793. If you read RFC 793, even in the 3-way handshake, the 3rd message had SEQ incremented! So, my guess is that it doesn't matter if it's incremented because the data part of the message is empty! (And that's the only explanation I can think of.) -- Bill Cheng // bill.cheng@usc.edu