Re: TCP AcK and Seq numbers...HELP [7:39393]
YOu can find it in Start of BRUCE CASLOW ROuting and Switching. Regards, TOM >From: "Juan Blanco" >Reply-To: "Juan Blanco" >To: [EMAIL PROTECTED] >Subject: TCP AcK and Seq numbers...HELP [7:39393] >Date: Sun, 24 Mar 2002 20:10:24 -0500 > >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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39395&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
Each OS is different. I'd search on google for tcp sequence numbers. -- RFC 1149 Compliant. Get in my head: http://sar.dynu.com ""Juan Blanco"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39396&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
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/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39397&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39442&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
What's the title & publisher? 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39454&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39482&t=39393 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: TCP AcK and Seq numbers...HELP [7:39393]
Sounds like a good book to have for the CIT exam as well as general reference. Does it cover the CIT exam topics? 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 > > > Prisc
Re: TCP AcK and Seq numbers...HELP [7:39393]
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 calculat
