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. 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? Is it a popular concept in the Linux world (so I can be familiar with)? 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... That's all for now, I might ask some more questions, but after some studying :s Thank you. P.S: I do have experience in C/C++ programming....in Bill Gates environment. I know.....I'm sorry.
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, -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Naordin,
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.
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? Is it a popular concept in the Linux world (so I can be familiar with)?
This is called the Reactor pattern and it is not at all restricted to Linux. It's not synchronous, it's synchronous event dispatching. This style of programming was popularized with the ACE Framework by Douglas Schmidt and a fairly well-known modern-day example is Twisted (Python): http://twistedmatrix.com/trac/. Another - simpler - example is libevent: http://www.monkey.org/~provos/libevent/. Here is a short overview on Wikipedia: http://en.wikipedia.org/wiki/Reactor_pattern - Lars
Hi Lars, Thank you for your explanation and your valuable links. I really appreciate it. Greetings, Nordin. Lars Immisch schreef:
Naordin,
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.
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? Is it a popular concept in the Linux world (so I can be familiar with)?
This is called the Reactor pattern and it is not at all restricted to Linux. It's not synchronous, it's synchronous event dispatching.
This style of programming was popularized with the ACE Framework by Douglas Schmidt and a fairly well-known modern-day example is Twisted (Python): http://twistedmatrix.com/trac/.
Another - simpler - example is libevent: http://www.monkey.org/~provos/libevent/.
Here is a short overview on Wikipedia: http://en.wikipedia.org/wiki/Reactor_pattern
- Lars
participants (3)
-
Harald Welte -
Lars Immisch -
Nordin