Sorry about the delay, I have no clear idea on this yet but IMHO, there could be two APIs to send OF messages to switches; asynchronously and synchronously:
The asynchronous API that only queues the message and sends it later. If it fails to send the message, notifies the caller via a callback function (if specified). The API returns an error immediately if the queue is full or the data plane is dead. The synchronous API that sends the message immediately and doesn't return until the data plane replies. As you know, switch doesn't reply to some of OF messages, e.g., FlowMod. I think that synchronous "send" API isn't fit for OF. We could have high level API like "set flows" that sends messages to data plane, makes sure that flows are installed by asking data plane, then returns. Thought? On Mon, 14 Mar 2016 17:26:29 +0000 Victor Orlikowski <[email protected]> wrote: > 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
