[ee122] flow control for project 2
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
I am just taking packets from the queue and putting them in the buffer
passed in from my_recv.
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
> 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.
> On Dec 5, 2007 10:08 PM, Amit Matani <amitmatani at berkeley.edu> wrote:
> > Oh okay. Still slightly confused, though. You said: "(Accordingly,
> > 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
> > have one thread of execution. If this is the case, and for example a
> > to my_recv asks for say 500 bytes. Then the transport layer could pass
> > packets it receives directly to the buffer passed in by my_recv until it
> > 500 bytes and then pass control of execution back to the receiving
> > Then the program could do the same thing for another 500 bytes etc.
> > 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
> > that
> > > > fills a staging buffer which is then processed by a processor
> > >
> > > 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
> > > layer that deals with recovering the bytestream transmitted by the
> > receiver,
> > > and another layer that consumes this bytestream at the application
> > >
> > > Thus, your receiver-side application repeatedly calls my_recv() to
> > > more of the bytestream until my_recv() finally indicates the
> > > has been closed. (Accordingly, your thread of execution on the
> > > 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
> > > the my_recv() caller, it has to deal with a finite buffer size - and
> > > 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...
More information about the ee122