On 08/27/2015 10:49 AM, lucien xin wrote: >> >> So one potential way is to have peer.rwnd and peer.a_rwnd, where peer.a_rwnd >> is >> the window advertised by peer and peer.rwnd and our estimation based on >> peer.a_rwnd. >> This way we will always know where we stand. >> >> Although I am not sure yet if we want to grow the peer structure any more. >> >> Another way is to have an estimate or 0-window probe bit/flags one the send >> side >> and set it when we do 0-window probe. This way we'd know that when 0-window >> probe >> bit is set, peer returned 0 window. >> > I think updating 0-window may happen in sctp_process_init() and > sctp_outq_sack(), > I don't think 0-window can be probed, cause unreachable and closing > window both has > no reply from peer. but we can update the 0-window bit in those two > functions. I just do > not know where there is a available bit we can use if won't change the > peer structure.
You can ignore INIT as the window will never be 0 (not allowed). The updates could happen at the end of sctp_outq_sack(). There some spare bits in peer if you want to go that way. -vlad > >> Just some thoughts. >> -vlad -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
