This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi!
I'm getting to a point where we need to associate more and more state
and/or references with every individual msgb.
In the circuit switched BSC case, every message (msgb) is associated with
a logical channel (lchan) through which it is sent.
However, in the packet switched case, this is not the case. Rather, a msgb
is received on a particular NS-VC, inside a particular BSSGP-VC, inside a LLC
session, etc.
When we pass a msgb through the protocol layers and back, we somehow need
to identify where to send the response to. Once we actually reach the
04.08/04.11 layer, things become a bit less difficult. In the end, all
messages are at least somehow associated with a 'subscriber'.
If a message passes from the UDP socket into the NS protocol and into BSSGP, we
need to know the BSVCI and NSVCI if we want to send a response back. One
option would be to pass those values as explicit function call arguments,
which is partially what my current code is doing. But the more layers we traverse, the longer the function arguments get.
Furthermore, there are parts of our protocol (04.08 and 04.11 particularly)
that can either be transported on top of 08.58 (RSL) or LLC/BSSGP/NS. Those
upper layers shouldn't really care what the underlying transport looks like.
One possible option is to somehow identify the NS-VC and BSSGP-VC by putting
an identifier or pointer into a 'struct msgb' member. This would require
libosmocore changes every time we add some bits here or there.
Another option is to introduce something similar to the skb->cb in the
linux kernel: A 'control buffer' area of unspecified content provide by the
core networking code as part of every sk_buff, which gets type-casted
to the IPCB or TCB-CB when the msgb enters the respective protocol layer.
The advantage is that we could have one msgb structure definition with the
typecasting functions/macros being part of the application (e.g. openbsc)
The problem with this is: Its scope is limited to whatever is the current layer
of the protocol stack. The IPCB is overwritten with the TCBCB once the
message enters TCP.
In our case, we would actually want to have the associated data to persist
even while the msgb passes from one layer into another. This would mean
that there is a more-or-less static structure containing all the various
identifiers, which is then typecasted to the control buffer.
While this might not be ideal, it definitely keeps the details hidden
away from libosmocore, which is good.
Any comments are welcome,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)