This is sort of my solution as well, with the only exception. Because
the switch might connect, disconnects and connect again before
the timer fires, in which case the if connected[dpid] will return true
although there was a disconnection in the middle, I also keep
track of which dpids currently
right. I guess timer1 should be refreshed only if the switch is still
connected, which means you'd need to keep track of connection status per
switch. When the switch disconnects, is that detected, and is a relevant
event raised?
If so, maybe you could do something like
handle_dp_join():
connect
Just to clarify, I am just asking if the spec allows the switch to
send a reply after a disconnection. Just want to make the spec more
rigorous.
Regards
KK
On 15 October 2010 00:27, Nicholas Bastin wrote:
> On Thu, Oct 14, 2010 at 23:58, kk yap wrote:
>>
>> Guess no one wants to read the lengt
On Thu, Oct 14, 2010 at 23:58, kk yap wrote:
> Guess no one wants to read the lengthy email. Here's the question
> with an re-enactment:
> 1. Switch connected to NOX
> 2. NOX send stat request
> 3. Switch disconnect from NOX
> 4. Switch reconnects to NOX
> Now, should or can the switch send the
Guess no one wants to read the lengthy email. Here's the question
with an re-enactment:
1. Switch connected to NOX
2. NOX send stat request
3. Switch disconnect from NOX
4. Switch reconnects to NOX
Now, should or can the switch send the stat reply for step 2?
I believe this what the FlowVisor is
I don't know what you mean by "responding to old stat requests".
-b
On Thu, Oct 14, 2010 at 9:30 PM, kk yap wrote:
> Okay,
>
> I see what is the problem with NOX, but it seems like there is also a
> problem with the FlowVisor.
>
> If a switch disconnects from NOX and reconnects, it would not (o
Oh, so it's not a specific single-shot timer (post()) that should be
canceled, but rather the periodical setup of a new post(), which I guess is
originally established in the dp_join handler. So it sounds like if the
reverse procedure is followed in dp_leave, i.e. cancel the periodical post
that wa
Okay,
I see what is the problem with NOX, but it seems like there is also a
problem with the FlowVisor.
If a switch disconnects from NOX and reconnects, it would not (or
rather should not) reply to old stat requests? This is the behavior
FlowVisor is presenting to NOX. I am not sure here. I be
Actually the problem arose because a switch was flapping,
i.e. it was connecting and disconnecting periodically, causing multiple
timers
to be set and ending in stat timers firing multiple times per second
requesting
for stats even when the switch was in the middle of establishing the
connectio
