On Mar 1, 2016, at 11:40 PM, Victor Orlikowski <[email protected]> wrote: > > 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.
So - just double-checking...should I alter send() and send_msg() to return True/False, based on whether the requested message was enqueued for send, so that applications can decide whether a Datapath is still valid or not? Previously, send() and send_msg() did not return any value; existing applications could ignore any return value we provide, and not be broken. If True/False is not the right thing to return - I am open to other suggestions. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
