[ee122] flow control for project 2

Amit Matani amitmatani at berkeley.edu
Wed Dec 5 22:20:54 PST 2007


I totally get that, but by doing it this way, how is the receiver's buffer
ever going to get overwhelmed in such a way that I have to reduce the
advertised window?  Since I let UDP queue up the packets in the kernel, I
have no idea what the strain is on the system and if UDP's queue is getting
overloaded.

I am just taking packets from the queue and putting them in the buffer
passed in from my_recv.

-Amit

On Dec 5, 2007 10:15 PM, Lisa Fowler <fowler at eecs.berkeley.edu> wrote:

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


More information about the ee122 mailing list