[olsr-dev] Re: olsr bmf question

[Erik Tromp]

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'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.
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>