This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
soc:2010:cooldavid:journal:week9 [2010/07/26 05:43]
soc:2010:cooldavid:journal:week9 [2010/07/26 08:42]
Line 100: Line 100:
 Michael Michael
 +Yes! And I think it is be better than what I did in
 +"[tcp] Receive and Close flow adjustment"​. to put xfer_deliver_iob()
 +in tcp_process_rx_queue() seems more reasonable.
 +I would be honored to put together a patch of the passive close
 +facility and the above you suggested on top of current iPXE TCP stack.
 +BTW, do you think it's reasonable to do something like:
 +"[tcp] Cleanup TCP closing actions"​ patch which it sumbitted
 +on gpxe-devel list?[2]
 +I think it might be useful for following reasons:
 +  1. We don't have to think of what would tcp_close() do if we call it
 +somewhere. The behavior of calling tcp_close() would be always the same.
 +  2. Reduced some duplicate code.
 +  3. We don't have to separate tcp_close() from tcp_rx_fin(). And have the same
 +behavior. Seems a little more neat to me.
 +Above results are accomplished by:
 +  1. Separate terminate action.
 +  2. Separate terminate action.
 +  3. Separate nullify xfer interface.
 +     ​(Which is part of "[tcp] Receive and Close flow adjustment"​[1])
 +Guo-Fu Tseng
 </​file>​ </​file>​

QR Code
QR Code soc:2010:cooldavid:journal:week9 (generated for current page)