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 <<a href="mailto:fowler@eecs.berkeley.edu">
fowler@eecs.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;">for example, file_recv would have a method that essentially does
<br>"receive and save until disconnected". That method is at the<br>app-level.<br><br>In the "receive and save until disconnected" method, you loop on<br>exactly that: receive and save, until disconnected, where "receive"
<br>in this case is a method that calls into your protocol's "receive x<br>bytes" function.<br><br>When entering the "receive x bytes", the size of x is the size of your<br>receiver window. 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. It returns those bytes to the<br>"receive and save until disconnected" method, which then saves, or
<br>returns upon disconnection.<br><br>Behind the scenes: The incoming packets from the sender will queue in<br>the UDP socket until "receive x bytes" is called again, and thus will<br>not be ACKed until "receive and save until disconnected" loops again,
<br>and enters "receive x bytes".<br><br>Does that help?<br><br>Don't use threads. You don't need to.<br><br>-Lisa<br><div><div></div><div class="Wj3C7c"><br>On Dec 5, 2007 10:08 PM, Amit Matani <<a href="mailto:amitmatani@berkeley.edu">
amitmatani@berkeley.edu</a>> wrote:<br>> Oh okay. Still slightly confused, though. You said: "(Accordingly, your<br>> thread of execution on the receiver side for the most part sits inside<br>> my_recv().)" so I am assuming that we block on calls to my_recv and we only
<br>> have one thread of execution. If this is the case, and for example a call<br>> to my_recv asks for say 500 bytes. Then the transport layer could pass the<br>> packets it receives directly to the buffer passed in by my_recv until it got
<br>> 500 bytes and then pass control of execution back to the receiving program.<br>> Then the program could do the same thing for another 500 bytes etc. until<br>> the close of connection is reported.<br>><br>
> So should we have a seperate thread to fill a buffer and when calling<br>> my_recv only transfer what we have in the buffer over to the calling<br>> program?<br>><br>> Thanks<br>> -Amit<br>><br>>
<br>><br>> On Dec 5, 2007 9:38 PM, < <a href="mailto:vern@cs.berkeley.edu">vern@cs.berkeley.edu</a>> wrote:<br>> ><br>> > > Since we are not using threading and passing<br>> > > control of the program to the my_recv function, we do not have a thread
<br>> that<br>> > > fills a staging buffer which is then processed by a processor thread.<br>> ><br>> > 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*
<br>> 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
<br>> 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>> ><br>><br>><br></div></div>> _______________________________________________
<br>> ee122 mailing list<br>> <a href="mailto:ee122@mailman.ICSI.Berkeley.EDU">ee122@mailman.ICSI.Berkeley.EDU</a><br>> <a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
</a><br>><br>><br></blockquote></div><br>