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.
<br><br>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?<br><br>Thanks <br>-Amit<br><br><div class="gmail_quote">On Dec 5, 2007 9:38 PM, <
<a href="mailto:vern@cs.berkeley.edu" target="_blank">vern@cs.berkeley.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> Since we are not using threading and passing<br>> control of the program to the my_recv function, we do not have a thread that<br>> fills a staging buffer which is then processed by a processor thread.
<br><br></div>That's not quite what we framed. Rather, we framed that (1) you don't<br>need to worry about concurrent connections, and (2) the *sender* application<br>can give the entire file to the transport protocol for transmission as
<br>a single unit. However, your receiver should still be layered with one<br>layer that deals with recovering the bytestream transmitted by the receiver,<br>and another layer that consumes this bytestream at the application layer.
<br><br>Thus, your receiver-side application repeatedly calls my_recv() to consume<br>more of the bytestream until my_recv() finally indicates the connection<br>has been closed. (Accordingly, your thread of execution on the receiver
<br>side for the most part sits inside my_recv().) Because your transport<br>layer at the receiver end needs to buffer up data and then return it to<br>the my_recv() caller, it has to deal with a finite buffer size - and hence
<br>you need flow control.<br><br> Vern<br></blockquote></div><br>