[music] Good day, viewers.
In this segment, we'll talk about flow
control.
Flow control is in addition to the sliding
window, to deal with the problem of making
sure that the receiver can handle the data
that the sender is sending to it.
So it's going to provide a way to slow
down an over enthusiastic sender.
You might wonder whether this is a real
problem.
Do we need to worry about receivers not
being able to handle data fast enough?
Well, yes actually.
So the sliding window is already using a
lot of pipelining to make sure we keep the
network busy.
But what we want to do with flow control
is make sure that in doing so, even though
we're keeping the network busy, as busy as
we can to use it all, we're not
inadvertently overloading the receiver.
You might have, for instance, you know, a
small mobile phone that's going to be a
little wimpier compared to some big
powerful server in the cloud, which can
send data with it possibly faster than the
phone could receive.
We'd like for our protocols to be able to
handle this case.
Okay, so let's zoom in on the sliding
window and how it works at the receiver.
So this is a receiver where we have
buffering for up to w buffers for out of
order packets.
Now, what is going to happen in the normal
case is that we'll have a sequence number,
this is here, LAS, the Last Ack Sent.
That is going to be the highest in order
acknowledgement that's being sent.
And as we receive new data, it's going to
go into the buffer, and then we'll pass it
up to the app.
The app will actually pull the data out of
that buffer, and we can slide our sliding
window and, and go ahead.
How does the app actually pull the data
out of that buffer?
It turns out we can relate this to
sockets.
It's done with a receive call.
So an app needs to call receive to get the
data out.
Hopefully a call is received before
because it's expecting data, it's just
waiting to get it.
But let's see what can happen under this
model.
Suppose that a couple of segments arrive
from the network but the, the app is a
little slow calling receive, so the
transport can't pass them up to the
application right away.
Maybe that was busy for some reason.
Well, two segments come in, that's these
two here.
Okay, so they're now full.
My LAS is going to go onto here.
Alright, so this is now LAS.
However, we can't really slide the window
yet, because we haven't been able to off
load these two segments and pass them to
the app.
As soon as we've done that, we're fine and
we can move the window along.
But if the apps slow, we can't send them
along yet.
What happens?
Oh, so here's a cleaned up version of that
diagram.
The conclusion here is that we can't
extend, slide the window just yet.
What happens now if before the app gets
its Ack together in calls received, more
segments come in from the network?
Here you can see another three segments
arrived here.
They went into the buffer.
We had room for them.
We updated LAS.
Great.
But we still haven't passed into the app
yet.
Now, this actually means we're in a very
unfortunate situation.
Because if more new segments arrive from
the other side, we don't have a place to
buffer then.
We'll have to throw them away.
That doesn't sound very good, but luckily
for us, the app now takes two segments.
So that must have been these two segments
here.
They are now shown as y because their
data's been passed up to the app.
So this means we can slide the window
along.
From its left edge being here, to where it
is now here.
And now we have another couple of buffers
available for new segments coming in from
the other side.
Phew, that was great, just in time.
But you can see, we got lucky in this
scenario, and with a slow receiver, we
could easily get.
What we would like to do with flow control
is come up with the mechanism whereby we
avoid these kinds of losses at the
receiver and we can do that by simply
telling the receiver how much buffer space
is available.
So what we would like to tell the receiver
is that for instance here there are three
buffer spots available.
That's this WIN the wis, the flow control
window which is the number of acceptable
Segments, or the buffer size there.
We want to tell it that and not
information about W, which the sender
knows, anyhow.
And these this win, number of acceptable
buffers, they're measured from LAS, from
when you sent the last.
Ack, because they're the next higher
segments which could be received.
So all we'll do with our flow control
protocol is simply send that information
back.
As well as the acknowledgement we'll send
this WIN information, the flow control
window.
The sender will then use the lower size,
the smaller size of the actual sliding
window .
W in the flow control window WIN and it
will pertain to the effective size in the
sliding window is this size.
Either of these vectors could be the
limiting factor.
For instance, we could be limited by the
amount of space in a flow control buffer
at the other side.
Or if we had a big fat buffer, we could
limited by the size of the sliding window
that the sender is using.
So either of these could be the So I'll
now show you an example of flow control,
just to put it all together.
And this is a fairly long example, so
it'll take us a, a little while to go
through it.
It's also a TCP-style example.
Here we use a sequence number.
And an acknowledgement number for the
sliding window.
These are both measured in bytes, they're
byte positions.
The flow control window is carried in a
variable called WIN, and the invariant
that we need for flow control is that the
byte sequence number plus the length of
the number of bytes we carry in a segment,
needs to be less than the, the ACK number
plus the flow control window.
Because if it's larger than that, it may
not fit in the buffer on the other side.
The receiver here also has a 4 kilobyte
buffer.
And it's a circular buffer.
So, the network fills it up.
Round and round and round.
And the application reads from the tail
end of the buffer, going around.
So let's see how it works.
Beginning, then we have the ACK sending 2
kilobytes here from the sequence number 0.
So that goes into the buffer.
What goes back?
The ACK goes back.
This ACK is for 2 kilobytes because that's
now the end here of the buffer.
The next place to write into it.
And our window has gone down into also two
kilobytes.
Because that's what's left of the 4
klobyte buffer.
Okay that's fine.
Now fora little while the app does another
send of 2 kilobytes.
What happens then?
Well we filled in this buffer, so you can
see the right head has gone around to the
beginning of the buffer again.
And the ACK that's going to come back is
going to acknowledge the n there.
We got to 4, we got to 4k of data has gone
through.
The window, however, is now 0.
There's no space left in the buffer.
Oh.
So the sender at this stage, right here,
actually from the very beginning here when
it went through, it knew that it had
filled up the flow, the buffer on the
other side, and so it was waiting for
information from the other side to say
there's a little more space.
It hasn't received it yet so the sender is
blocked at this stage.
Sometime later here our buffer is full.
We haven't done anything with it yet, but
sometime later here the application will
do a read.
It will read from the beginning of the
buffer through.
So it will read up to here, that's 2
kilobytes.
If that's the case, we now have 2
kilobytes free.
So, we will.
Oh, sorry, I just drew over that one we
did, send that back.
But now, after the application's
reinstated, we're going to send another
app back.
This app will have the same acknowledgment
number because no new data is being
received from the other side.
But the window will be updated to say hey
there's now two kilobytes of free space in
this buffer.
When the sender receives that here the
sender knows, that he can actually send
some more data if it wants.
It feels very happy and pleased about
this, and it decides go ahead and now it
sends another 1 kilobyte of data.
From the sequence number of 4K.
That one kilobyte of data goes into the
buffer there, so we, we filled it up just
a little bit there.
And you can see we now have 1 kilobyte
left.
So if I was to go a little further here,
then you would see an ACK.
You can do the math here for 5K and a win,
what do you think it will be?
It should be for 1K, because that's all
that's left.
So both of those will be on here.
Great, okay, well that's the end of our
example, and now, you, you've seen how
flow control works.
Wyszukiwarka
Podobne podstrony:
Virtual Threads Beware Ethernet flow control06 Control of respiratory functions Sleep apnea syndrome PLidb71Control Flow Graphs as Malware Signatures04 Conditionals and Control Flow2010 06 Git in Control Flexible, Powerful, and Usable Version ControlControl flowTech tech chem11[31] Z5 06 ucontrol structures continuesrodki ochrony 06[1]06 (184)0612 control statementswięcej podobnych podstron