5 Jun
2009
5 Jun
'09
12:35 p.m.
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.
5 Jun
5 Jun
1:21 p.m.
New subject: Trying to understanding the source
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:45 p.m.
New subject: Trying to understanding the source
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
8 Jun
8 Jun
11:19 a.m.
New subject: Trying to understanding the source
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
5860
days inactive
5863
days old
3 comments
3 participants
participants (3)
-
Harald Welte -
Lars Immisch -
Nordin