Hi, The choice is yours.
To do a synchronous call, send the flow_mod followed up a barrier_request. You will get the barrier_reply back. To do asynchronous calls, just send the flow_mod and wait for error messages. The error messages should carry the same xid (transaction id) as the flow_mod and the flow_mod generated the error. You do not need to tweak TCP options for this. It is usu. done in an async manner. If you are using a controller like NOX, then this should not really be of much concern. Are you whipping up a new controller? Regards KK On 20 May 2011 13:11, G A <ga_a...@yahoo.com> wrote: > Hi all > > What is the expected/standard way to handle error messages to flow_mod > requests? > > If they are treated as SYNC messages, then my application would have to wait > for > an ack. But if the switch has happily accepted the flow_mod, it does not send > back anything - causing my app to hang forever. > > If they are treated as ASYNC messages, then my application fires off a > flow_mod > and hopes all's well and goes about doing other things. Sometime later an > async > error message might be received. Now my app's in trouble since I have already > done things I shouldn't have and rolling back can be messy. > > One workaround to this might be: Send a flow_mod message. Set socket.timeout > for a second maybe and if nothing arrived yet, then we can safely assume all's > well. But this seems to be a very bad hack since the app has to wait > unnecessarily even if things have gone well. > > Any other suggestions ? > > regards > Gopal Agrawal > > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
