OK,
See if I have it here.
The receive window is a buffer. It is specified in bytes. During the 3 way
handshake, each side tells the other it's buffer size. This is the start of
our flow control.
During the 3 way handshake, Each side also specifies a sequence number. The
other will
of Stevens, TCP/IP Illustrated, page 266-267. And this
appears
to be happening in the sniffer trace that I was examine.
Brett
-Original Message-
From: Ayers, Michael [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 11:21 AM
To: [EMAIL PROTECTED]
Subject: RE: TCP Ack [7:11703]
OK
OK I'm reposting because my original got cut off.
See if I have it here.
The receive window is a buffer. It is specified in bytes. During the 3 way
handshake, each side tells the other it's buffer size. This is the start of
our flow control.
During the 3 way handshake, Each side also specifies
At 11:09 PM 7/10/01, Michael L. Williams wrote:
You're correct, and I should be more careful with my terminology
segments are what TCP deals with I'm wondering how you could get away
with writing an RFC that doesn't specify something as critical as sending
ACKs =)
Well, I think the
At 01:29 PM 7/11/01, Ayers, Michael wrote:
OK I'm reposting because my original got cut off.
See if I have it here.
The receive window is a buffer. It is specified in bytes. During the 3 way
handshake, each side tells the other it's buffer size. This is the start of
our flow control.
During
OK, last try on my post
The receive window is a buffer. It is specified in bytes. During the 3 way
handshake, each side tells the other it's buffer size. This is the start of
our flow control.
During the 3 way handshake, Each side also specifies a sequence number. The
other will reply with
:RE: TCP Ack [7:11703]
At 01:29 PM 7/11/01, Ayers, Michael wrote:
OK I'm reposting because my original got cut off.
See if I have it here.
The receive window is a buffer. It is specified in bytes. During the 3
way
handshake, each side tells the other it's buffer size. This is the start
i think this is because the window size is allowed to get much larger
befrore something gets dropped on a higer speed segment.
i think sending the window size is still used.
also dont forget that sometimes ICMP is used to control certain things.
of course you've read the rfcs, the
At 10:01 AM 7/10/01, Peter Slow wrote:
i think this is because the window size is allowed to get much larger
befrore something gets dropped on a higer speed segment.
Would a TCP recipient know it was on a high-speed segment, though? A sender
might have some idea because it tracks congestion,
Comments below..
Priscilla Oppenheimer wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
At 10:01 AM 7/10/01, Peter Slow wrote:
i think this is because the window size is allowed to get much larger
befrore something gets dropped on a higer speed segment.
Would a TCP
At 06:38 PM 7/10/01, Michael L. Williams wrote:
Comments below..
Priscilla Oppenheimer wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
At 10:01 AM 7/10/01, Peter Slow wrote:
i think this is because the window size is allowed to get much larger
befrore something gets
NICE!
See below.
Priscilla Oppenheimer wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
A recipient is not told to use a window size by the sender. Each side has
its own receive window size, based on its own buffer space. It used to be
that a recipient ACKed when it
12 matches
Mail list logo
