[ee122] flow control for project 2

[Lisa Fowler]

for example, file_recv would have a method that essentially does
"receive and save until disconnected".  That method is at the
app-level.

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
bytes" function.

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.

-Lisa

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
> 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
> >
>
>
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>