I'm still analyzing the inter-bro(1.1) communication
RemoteSerializer.cc
line 634/635 and 637/638 are identical:
if(our_class)
p->our_class = our_class ;
SocketComm::Run (): lines 2333 to 2361
[1] if ( io->IsFillingUp() && ! shutting_conns_down ) {}
and [2] if ( ! io->IsFillingUp() && shutting_conns_down ) {}
example:
- bro node A is connected to nodes B and C.
- B sent 4GB, C only 20MB
- now C generates much traffic and A's queue to parent is filling up
-> [1] becomes true, but instead of C, B is detected as the connection with the heaviest traffic and therefor disconnected;
shutting_conns_down = true.
- C still floods A, [1] and [2] are false and C can't be stopped. (?)
My solution:
[a] 'bytes_read' should be a dynamic value. I think this consumes more resources than [b], but will detect the heaviest connection
[b] a timeout to set 'shutting_conns_down = false' if 'io->IsFillingUp()' is still true. Problem: in worst case, it will disconnect all notes and the heaviest connection is the last one.
afaik this is just a band aid until we've implemented an app-layer flow
control scheme -- killing a connection is suboptimal in any case. Is the
issue you're describing a problem you're seeing in practice?
I'm still analyzing the inter-bro(1.1) communication
Seems you're doing a thorough code review.
RemoteSerializer.cc
line 634/635 and 637/638 are identical:
if(our_class)
p->our_class = our_class ;
That's pretty certainly a left-over from merging in a patch at some
point. I'll get rid of the duplicate.
- C still floods A, [1] and [2] are false and C can't be stopped. (?)
Yes, you're right. Like Christian, I'd be interested to know whether
you've run into this problem in practice.
As Christian also mentioned, shutting connections down is only kind
of an emergency break, lacking something more sophisticated at the
moment. However, one of your solutions (I'm tending towards [b])
might be worth implementing if this turns out to be problematic.
more or less, i'm writing a short (german) documentation how inter-bro communication can be used for mobile WLAN clients - so I have to understand how it works.
>> - C still floods A, [1] and [2] are false and C can't be stopped. (?)
>
> Yes, you're right. Like Christian, I'd be interested to know whether
> you've run into this problem in practice.
No, it was just an idea while reading the code.
> As Christian also mentioned, shutting connections down is only kind
> of an emergency break, lacking something more sophisticated at the
> moment. However, one of your solutions (I'm tending towards [b])
> might be worth implementing if this turns out to be problematic.
>
> Thanks for pointing these things out!
What is done in the state synchronization? I tried to figure it out, but it was too complex.
more or less, i'm writing a short (german) documentation how inter-bro
communication can be used for mobile WLAN clients
Cool! Can you send me a copy when you're done? (Or even before if
you'd like to get feedback.)
What is done in the state synchronization?
It works. Just setup the connections between peers as you do for
event-passing and then declare some script variables (e.g., tables)
to be &synchronized. All operations performed on these variables
will then be propagated across the peers, and all of them will share
the same view of the synchronized state.
