On Fri, Jun 05, 2009 at 02:35:39PM +0200, Nordin wrote:

Hi guys,

I'm a bit ashamed to ask, but I'll ask anyway, could someone help me explaining the OpenBSC source?

make_sock(): I didn't know it's possible to call select() on a read signal to finally call the accept() for the socket_fd. Logically seen, socket_fd receives something (in this case a new connection), so it works. I just thought select() is only used for reading/writing data (or an except) on file descriptors.

This is normal operation for asynchronous select() based network daemons.

Why is OpenBSC written to work synchronously and not multihtreaded? If somewhere in the chain hangs (by a bug), telnet for example won't respond, right? What is the idea behind this concept?

The idea is to avoid the significant increase in complexity making all data structures and the code architecture thread safe, avoid race conditions, etc.

Threads just horribly complicate things, and typically they're not really needed.

As indicated, I'm perfectly fine with putting the actual voice data processing and TRAU muxing into a separate process. But more than that would be simply over-engineering. We're not trying to build a commercial grade BSC with hundreds of BTS and [tens of] thousands of handsets roaming back and forth between them.

We want to build something simple for protocol and security experiments, which will likely only see deployment in small setups.

So we stick to KISS (Keep It Simple / Stupid)

Is it a popular concept in the Linux world (so I can be familiar with)?

Yes, I think it is fairly popular in the unix network daemon world.

Which other functions does timer.c has besides returning a timevalue for the select() call (nearest_timer) time-out. I mean what more other purposes has timer.c Cause I don't really understand why timer_values also be put in a doubly linked list...

it manages a list of timers, and determines the timeout to the shortest current timer. once a timer expires, it calls the per-timer specific callback functoin.

Regards,