At 06:51 PM 3/25/02, Tom Lisa wrote: >Sounds like a good book to have for the CIT exam as well as general >reference. Does it cover the CIT exam topics?
Yes, Troubleshooting Campus Networks will cover all the CIT exam topics. That's one of its main goals. It's also good for CCIE candidates, especially those who care about what's happening behind the scenes on the wired (or wireless) medium. >Prof. Tom Lisa, CCAI >Community College of Southern Nevada >Cisco ATC/Regional Networking Academy > > > >Priscilla Oppenheimer wrote: > > > At 02:45 PM 3/25/02, Tom Lisa wrote: > > >What's the title & publisher? > > > > Troubleshooting Campus Networks (with Joseph Bardwell, who wrote the > > wireless and Windows chapters). The publisher is Wiley (though I still > > recommend Cisco Press books too.) You can order it at Amazon today. &;-} > > Thanks for asking. > > > > >Prof. Tom Lisa, CCAI > > >Community College of Southern Nevada > > >Cisco ATC/Regional Networking Academy > > > > > >Priscilla Oppenheimer wrote: > > > > > > > John has described the three-way handshake, which is used for session > > > > establishment. Once the session has been established, both sides >sequence > > > > their bytes that they send and both sides ACK the other side's bytes. > > > > Remember it's a stream-oriented protocol. Each side has a stream of >bytes > > > > it needs to send. > > > > > > > > When a sender sends data, the sequence number that it puts in the >packet > > is > > > > the sequence number of the first byte in the packet. The packet has a > > > > certain number of bytes in it, that is, a length. You should expect the > > > > sequence number in the next packet from this sender to be (seq + >length) > > >-1. > > > > > > > > The sender will keep sending as long as it has not gotten to the end of > > its > > > > send window. Then it must stop and wait for an ACK from the other side. > > The > > > > sender's send window is based on the recipient's receive window. The > > > > recipient states the size of its receive window in every packet. It is >an > > > > indication of how much memory the recipient has for receiving bytes and > > how > > > > much is used up at this point in time. > > > > > > > > The recipient ACKs every byte, but not explicitly. The recipient sends >a > > > > packet with the ACK bit set and the ACK number set to the next byte >that > > > > the recipient expects to receive. By stating the next byte it expects >to > > > > receive, the recipient acknowledges receiving the bytes before this. > > > > > > > > The recipients is not required to send an ACK the instant it receives > > data. > > > > In fact, a host can reduce network overhead and increase efficiency by > > > > sending fewer ACKs. This is known as delayed ACKs. The "Host >Requirements > > > > RFC" (RFC 1122) states that a TCP implementation should implement >delayed > > > > ACKs, but an ACK should not be excessively delayed. In particular, the > > > > delay must be less than 0.5 seconds, and when receiving a stream of > > > > full-sized segments, there should be an ACK for at least every second > > > > segment. Most implementations do not wait a full 0.5 seconds, which >would > > > > seem awfully long on modern networks. Upon receipt of a TCP segment, a > > host > > > > sets an ACK timer. When the timer elapses, the host acknowledges data > > > > received so far. A typical value for the ACK timer is 0.2 seconds. > > > > > > > > One reason for delaying an ACK is that the host may have its own data >to > > > > send in the same direction as the ACK. The data can be sent with the >ACK, > > > > which avoids extra network traffic caused by so-called empty ACKs. An >ACK > > > > that is sent with data is sometimes called a piggyback ACK. > > > > > > > > All of this is best described with an example. However, that would take > > too > > > > long in this forum. But stay tuned for my new book which will have > > > > examples. I have finished the writing. I'm still waiting for the > > publisher > > > > to do their business. > > > > > > > > Priscilla > > > > > > > > At 09:21 PM 3/24/02, John Green wrote: > > > > >i know there are many more knowledgeable here but just > > > > >lets get started with this thread. > > > > > > > > > >Source sends a syn packet to the destination and this > > > > >packet contains sequence number(say x) and ACK bit not > > > > >set > > > > >The destination receives it and sends a syn and ack. > > > > >this packet contains its sequence number(say y) and > > > > >ACK bit or flag is set > > > > >Source recieves the syn and ack and sends back an > > > > >ack back to destination. > > > > > > > > > >destination receives the ack and tcp connection is > > > > >established henceforth. > > > > >Refer RFC 793 for further details. (but any tcp/ip > > > > >book would deal with this) > > > > > > > > > >--- Juan Blanco wrote: > > > > > > Team, > > > > > > > > > > > > Do any one knows where I could find any document > > > > > > that explain how calculate > > > > > > the TCP Ack and Seq numbers. Any explanation will be > > > > > > appreciate. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > JB > > > > >[EMAIL PROTECTED] > > > > > > > > > > > > > > >__________________________________________________ > > > > >Do You Yahoo!? > > > > >Yahoo! Movies - coverage of the 74th Academy Awards. > > > > >http://movies.yahoo.com/ > > > > ________________________ > > > > > > > > Priscilla Oppenheimer > > > > http://www.priscilla.com > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39491&t=39393 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
