Ah; OK. So, since we were trying to close file descriptors properly, there's one of two ways to accomplish that: 1) Have an echo request loop that does it automatically (and we now have available, but not enabled by default). 2) Have the application call close() on a Datapath that it considers "stale" - i.e. replaced by another Datapath, etc. With the echo request loop disabled, if a switch OF agent "goes away" without a proper TCP close, the stale Datapath will stick around if the application does not notice that a new Datapath (having the same DPID) replaced it.
The only way an application *might* notice that a Datapath is stale, in this case, is by trying to do a send() on it (as you mention). When this happens, the sendall() will either time out or error, and the Datapath will be closed. The problem, however, with that approach is that a send() on a Datapath that fails does not relay to the application that it failed; the application merely calls send(), and it might quietly fail. As of today, send() on a Datapath does not return an error to the application that calls it. The behavior you describe would require that behavior. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Mar 1, 2016, at 8:19 PM, FUJITA Tomonori <[email protected]> wrote: > > Probably, I don't understand what problem is this patch trying to > solve. > > I thought that the problem is about leaking opened file > descriptors. If so, the core closes a connection when a datapath is > dead. Applications might record or not, doesn't matter. After the core > closes the connection, if an application keeps the datapath and tries > to write to the connection, it gets an error. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
