[ee122] flow control for project 2

[Amit Matani]

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
program?

Thanks
-Amit

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
> that
> > 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*
> application
> 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
> receiver,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071205/7dca2201/attachment.html