[ee122] flow control for project 2
fowler at eecs.berkeley.edu
Wed Dec 5 22:15:56 PST 2007
for example, file_recv would have a method that essentially does
"receive and save until disconnected". That method is at the
In the "receive and save until disconnected" method, you loop on
exactly that: receive and save, until disconnected, where "receive"
in this case is a method that calls into your protocol's "receive x
When entering the "receive x bytes", the size of x is the size of your
receiver window. Your protocol will then receive and ACK up to x
bytes, returning x bytes or less/something else if it was disconnected
while trying to receive x bytes. It returns those bytes to the
"receive and save until disconnected" method, which then saves, or
returns upon disconnection.
Behind the scenes: The incoming packets from the sender will queue in
the UDP socket until "receive x bytes" is called again, and thus will
not be ACKed until "receive and save until disconnected" loops again,
and enters "receive x bytes".
Does that help?
Don't use threads. You don't need to.
On Dec 5, 2007 10:08 PM, Amit Matani <amitmatani at berkeley.edu> wrote:
> Oh okay. Still slightly confused, though. You said: "(Accordingly, your
> thread of execution on the receiver side for the most part sits inside
> my_recv().)" so I am assuming that we block on calls to my_recv and we only
> have one thread of execution. If this is the case, and for example a call
> to my_recv asks for say 500 bytes. Then the transport layer could pass the
> packets it receives directly to the buffer passed in by my_recv until it got
> 500 bytes and then pass control of execution back to the receiving program.
> Then the program could do the same thing for another 500 bytes etc. until
> the close of connection is reported.
> So should we have a seperate thread to fill a buffer and when calling
> my_recv only transfer what we have in the buffer over to the calling
> On Dec 5, 2007 9:38 PM, < vern at cs.berkeley.edu> wrote:
> > > Since we are not using threading and passing
> > > control of the program to the my_recv function, we do not have a thread
> > > fills a staging buffer which is then processed by a processor thread.
> > That's not quite what we framed. Rather, we framed that (1) you don't
> > need to worry about concurrent connections, and (2) the *sender*
> > can give the entire file to the transport protocol for transmission as
> > a single unit. However, your receiver should still be layered with one
> > layer that deals with recovering the bytestream transmitted by the
> > and another layer that consumes this bytestream at the application layer.
> > Thus, your receiver-side application repeatedly calls my_recv() to consume
> > more of the bytestream until my_recv() finally indicates the connection
> > has been closed. (Accordingly, your thread of execution on the receiver
> > side for the most part sits inside my_recv().) Because your transport
> > layer at the receiver end needs to buffer up data and then return it to
> > the my_recv() caller, it has to deal with a finite buffer size - and hence
> > you need flow control.
> > Vern
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
More information about the ee122