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.
<br><br>I am just taking packets from the queue and putting them in the buffer passed in from my_recv. <br><br>-Amit<br><br> <div class="gmail_quote">On Dec 5, 2007 10:15 PM, Lisa Fowler &lt;<a href="mailto:fowler@eecs.berkeley.edu">
fowler@eecs.berkeley.edu</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">for example, file_recv would have a method that essentially does
<br>&quot;receive and save until disconnected&quot;. &nbsp;That method is at the<br>app-level.<br><br>In the &quot;receive and save until disconnected&quot; method, you loop on<br>exactly that: &nbsp;receive and save, until disconnected, where &quot;receive&quot;
<br>in this case is a method that calls into your protocol&#39;s &quot;receive x<br>bytes&quot; function.<br><br>When entering the &quot;receive x bytes&quot;, the size of x is the size of your<br>receiver window. &nbsp;Your protocol will then receive and ACK up to x
<br>bytes, returning x bytes or less/something else if it was disconnected<br>while trying to receive x bytes. &nbsp;It returns those bytes to the<br>&quot;receive and save until disconnected&quot; method, which then saves, or
<br>returns upon disconnection.<br><br>Behind the scenes: &nbsp;The incoming packets from the sender will queue in<br>the UDP socket until &quot;receive x bytes&quot; is called again, and thus will<br>not be ACKed until &quot;receive and save until disconnected&quot; loops again,
<br>and enters &quot;receive x bytes&quot;.<br><br>Does that help?<br><br>Don&#39;t use threads. &nbsp;You don&#39;t need to.<br><br>-Lisa<br><div><div></div><div class="Wj3C7c"><br>On Dec 5, 2007 10:08 PM, Amit Matani &lt;<a href="mailto:amitmatani@berkeley.edu">
amitmatani@berkeley.edu</a>&gt; wrote:<br>&gt; Oh okay. &nbsp;Still slightly confused, though. &nbsp;You said: &quot;(Accordingly, your<br>&gt; thread of execution on the receiver side for the most part sits inside<br>&gt; my_recv().)&quot; so I am assuming that we block on calls to my_recv and we only
<br>&gt; have one thread of execution. &nbsp;If this is the case, and for example a call<br>&gt; to my_recv asks for say 500 bytes. &nbsp;Then the transport layer could pass the<br>&gt; packets it receives directly to the buffer passed in by my_recv until it got
<br>&gt; 500 bytes and then pass control of execution back to the receiving program.<br>&gt; Then the program could do the same thing for another 500 bytes etc. until<br>&gt; the close of connection is reported.<br>&gt;<br>
&gt; So should we have a seperate thread to fill a buffer and when calling<br>&gt; my_recv only transfer what we have in the buffer over to the calling<br>&gt; program?<br>&gt;<br>&gt; Thanks<br>&gt; -Amit<br>&gt;<br>&gt;
<br>&gt;<br>&gt; On Dec 5, 2007 9:38 PM, &lt; <a href="mailto:vern@cs.berkeley.edu">vern@cs.berkeley.edu</a>&gt; wrote:<br>&gt; &gt;<br>&gt; &gt; &gt; Since we are not using threading and passing<br>&gt; &gt; &gt; control of the program to the my_recv function, we do not have a thread
<br>&gt; that<br>&gt; &gt; &gt; fills a staging buffer which is then processed by a processor thread.<br>&gt; &gt;<br>&gt; &gt; That&#39;s not quite what we framed. &nbsp;Rather, we framed that (1) you don&#39;t<br>&gt; &gt; need to worry about concurrent connections, and (2) the *sender*
<br>&gt; application<br>&gt; &gt; can give the entire file to the transport protocol for transmission as<br>&gt; &gt; a single unit. &nbsp;However, your receiver should still be layered with one<br>&gt; &gt; layer that deals with recovering the bytestream transmitted by the
<br>&gt; receiver,<br>&gt; &gt; and another layer that consumes this bytestream at the application layer.<br>&gt; &gt;<br>&gt; &gt; Thus, your receiver-side application repeatedly calls my_recv() to consume<br>&gt; &gt; more of the bytestream until my_recv() finally indicates the connection
<br>&gt; &gt; has been closed. &nbsp;(Accordingly, your thread of execution on the receiver<br>&gt; &gt; side for the most part sits inside my_recv().) &nbsp;Because your transport<br>&gt; &gt; layer at the receiver end needs to buffer up data and then return it to
<br>&gt; &gt; the my_recv() caller, it has to deal with a finite buffer size - and hence<br>&gt; &gt; you need flow control.<br>&gt; &gt;<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Vern<br>&gt; &gt;<br>&gt;<br>&gt;<br></div></div>&gt; _______________________________________________
<br>&gt; ee122 mailing list<br>&gt; <a href="mailto:ee122@mailman.ICSI.Berkeley.EDU">ee122@mailman.ICSI.Berkeley.EDU</a><br>&gt; <a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
</a><br>&gt;<br>&gt;<br></blockquote></div><br>