[olsr-dev] Re: olsr bmf question
Ignacio García Pérez
(spam-protected)
Thu Dec 21 09:35:10 CET 2006
Erik Tromp escribió:
> Using add_olsr_socket is a good idea. It would eliminate the need for a separate thread. However the select() function is called by
> the OLSR deamon only every "Pollrate" seconds, which would make the packet forwarding rather slow.
>
I see. I think this is a bad design, and imposes a lot of limitations on
the usage of add_olsr_socket.
As far as I know, the OLSR daemon just needs to:
1- Execute some processes periodically (expiration of messages and such).
2- See if there is something to read from one of the sockets under its
control.
As it is done now, (2) is in reality done by (1), which imposes the
severe limitations stated above.
However, IT IS POSSIBLE and RELATIVELY EASY to do it the proper way,
though I'm afraid it would take a rewrite of much code:
One cau specify a timeout in the select() call. USE IT. However, there
is a catch: when there is data available on one of the sockets, the call
will return, data will be processed, but we still have to wait the
remaining period of time until the previously specified wakeup time.
The timeout parameter is passed to the select() call as a pointer, so it
COULD return the remaining time there. In fact, IT DOES in linux, thus
implementation of this scheme in linux is perfectly possible (I've done
that before), but this is a particularity of linux. In fact, posix says
the timeout return value of select() is undefined, so the problem would
be the implementation on other operating systems.
IMHO, the locking problem must be addressed somehow and soon, because I
think it hampers the development of olsr plugins, which seems to be one
of its bests strenghts. As we have discusses before, there are two ways
to do this:
1- Multi thread, and provide appropriate locking mechanisms.
2- Single thread (as it is now), but rewrite the scheduler main loop in
the above described way.
The current single thread scheme is nice, because one does not have to
deal with the usual locking headaches (deadlocks and such). However,
IMHO it has a serious limitation: gives too much power to plugins. As it
is actually sort of cooperative multitasking, any DOS attack to a plugin
will bring the whole olsr daemon (and network) to its knees.
Any thoughs? (specially interested in yours, Andreas).
Nacho.
> I'm not sure what is the best way to solve the possible locking issue.
>
> Have you tried to comment out the call to IsNullMacAddress so that BMF accepts the SLIP interface?
>
> Regards,
>
> ----- Original Message -----
> From: "Ignacio García Pérez" <(spam-protected)>
> To: "Erik Tromp" <(spam-protected)>
> Sent: Thursday, December 14, 2006 9:02 AM
> Subject: Re: olsr bmf question
>
>
>
>> Erik Tromp escribió:
>>
>>> Could you try to comment out the code that checks for the null MAC address? I'm considering to remove the check, if the
>>>
> interface is
>
>>> specified as an OLSR interface. In that way the BMF will fully follow the configuration of OLSR, regardless of any peculiarities
>>>
> of
>
>>> the network interface.
>>>
>>> About the multi-threadedness of OLSR-BMF: yes you are right. The probability is small, but it might (and will) occur that
>>> olsr_lookup_mprs_set() is called while the OLSR main thread is modifying something. I would like there to be a mutex (or other
>>>
> lock
>
>>> mechanism) offered by OLSR in all functions that may be called by plugins. Your recent post on (spam-protected) hits the spot.
>>>
> I
>
>>> have a slight preference of that above having an entry point into the OLSR call to select() . Having an entry point into the
>>>
> OLSR
>
>>> call to select() requires a new API that the current OLSR implementation does not offer.
>>>
>>>
>> I think it does: add_olsr_socket. Adds your socket to the olsr select()
>> and calls your function when data is available on it.
>>
>> Give the scheduler callback facility that the olsr core provides, I
>> think that almost all applications can be implemented without resorting
>> to pthreads.
>>
>> On on hand certain things are indeed much easier to implement using
>> pthreads, but on the other the collaborative pseudo-thread scheme lets
>> you forget about the locking issues, which is definitely a big
>> advantage. Maybe Andreas decided not to provide a locking mechanism to
>> force everyone to use the collaborative approach.
>>
>>
>>> Is it OK if I forward this mail to (spam-protected) ?
>>>
>>>
>> Sure!
>>
>>
>>> Regards,
>>>
>>>
>>> ----- Original Message -----
>>> From: "Ignacio García Pérez" <(spam-protected)>
>>> To: "Erik Tromp" <(spam-protected)>
>>> Sent: Wednesday, December 13, 2006 11:58 AM
>>> Subject: Re: olsr bmf question
>>>
>>>
>>>
>>>
>>>> Erik Tromp escribió:
>>>>
>>>>
>>>>> Hi Nacho,
>>>>>
>>>>> I surely think there is a way to BMF over a SLIP or PPP connection.
>>>>> In our research we are also routing over PPP, using OLSR. However,
>>>>> I never tried to multi/broadcast over such a connection. The only small
>>>>> problem may be that there is no broadcast address defined over a
>>>>> PPP connection. But that should be easy to overcome.
>>>>>
>>>>> I will take a look into it and see if I can come up with a solution. Just
>>>>> give me a few days.
>>>>>
>>>>> In the meantime, try to run OLSR over your SLIP interface. BMF
>>>>> will run on each interface on which OLSR is configured to run.
>>>>>
>>>>>
>>>> I already tried that and doesn't work. I placed some debug messages
>>>> around and found out that the BMF code simply ignores the OLSR
>>>> interfaces with NULL MAC addresses, which is the case of SLIP interfaces.
>>>>
>>>> (search for "if (IsNullMacAddress" in NetworkInterfaces.c)
>>>>
>>>> By the way, I've been studying the code of several plugins including
>>>> yours, and have a couple of questions about your implementation:
>>>>
>>>> You are using a sepparate thread to do the BMF stuff, which uses OLSR to
>>>> find about the MPRs. You are not using any mutex, so, isn't there a
>>>> serious risk of a race condition?
>>>>
>>>> I mean that the OLSR structures you are reading may change while you do.
>>>>
>>>> Wouldn't it be better to register the sockets with OLSR and let its
>>>> select() loop do the job?. That way there is only one thread (the OLSR
>>>> one) and there would be no locking issues.
>>>>
>>>>
>>>>
>>>>> Note that for a ppp/slip interface, the Ip4Broadcast parameter in
>>>>> olsrd.conf must be 255.255.255.255, e.g:
>>>>>
>>>>> Interface "ppp0"
>>>>> {
>>>>> Ip4Broadcast 255.255.255.255
>>>>> # using defaults for all other parameters
>>>>> }
>>>>>
>>>>> Regards,
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ----- Original Message -----
>>>>>>
>>>>>>
>>>>>>>>> Ignacio García Pérez <(spam-protected)> 12-12-2006 12:26:38 >>>
>>>>>>>>>
>>>>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just tried your bmf plugin today and could not make it work. The
>>>>>> problem is that my network is made of nodes connected point-to-point
>>>>>> through SLIP interfaces (over RS422). Obviously these interfaces do not
>>>>>> have an ethernet MAC address and are ignored by the bmf plugin.
>>>>>>
>>>>>> Actually, I do not need multicast capabilities, just broadcast, which I
>>>>>> guess is much easier to implement on top of olsr than multicast.
>>>>>>
>>>>>> Anyway, in order to *not* invent the wheel again, do you think there is
>>>>>> a way to use your bmf plugin over a SLIP interface ?.
>>>>>>
>>>>>> I've had a quick look to the code to see how tight it is bound to the
>>>>>> ethernet layer and seems that it is just because of the MAC filtering
>>>>>> facility that the plugin has for debugging. Is that right?
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> Nacho.
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>
>
More information about the Olsr-dev
mailing list