[ee122] flow control for project 2

[vern at cs.berkeley.edu]

> 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