Hi Neels,
21:14 < neeels> LaF0rge, I need a solution for picking a conn_id as an SCCP SAP user. The way osmo-bsc does it isn't much good either. There has to be some way to obtain an unused local reference without running into potential collisions 21:16 < neeels> (I submitted the patch expecting your -1, but just to make sure that I understood correctly I wanted to submit as code that has no room for misunderstandings) 21:18 < neeels> if I can't use the internal "next_id" thing, then what I would have to do is mimick the exact same in osmo-msc by looking up what conn_ids are already in use and pick an unused one. That's quite brain damaged IMHO, it's the same thing as that layer violation patch, only with much more effort and more chances for id collisions.
Nobody is suggesting that.
21:21 < neeels> ideas: add some primitive to hand out a local reference -- but that would be non-standard IIUC
I had mentioned and discarded that option in Message-ID: 20190311204817.GA725@nataraja here on this list. The reason is not that it's non-standard, but that it again wouldn't work over any type of asynchronous / message based SAP [and that's how a SAP is conceptualized].
21:21 < neeels> give each application some unique number space for local references, like the highest byte is configured in .cfg file, and then each SCCP user cycles through its own number space of local references 21:23 < neeels> ...and libosmo-sccp would have to be constrain-able to its own number space for incoming connections
I was quite sure we've had that discussion before. Unfortuantely it doesn't seem to be on this mailing list or in gerrit. It may have been on IRC or I am starting to be delusional :/
The correct solution from the spec / SCCP architecutre point of view is rather clear, I think:
* don't recycle the SCCP local reference (protocol) from the SCCP connection ID (SAP), but use distinct number spaces for that. It was an oversimplification to do that in the original implementation. I simply missed the different scoping of those two identifiers. The scoping is the root of our problems here.
* only once we have distinct identifiers, we can fix the scope: One of the two identifiers has a per-SCCP-user scope, while the other has a per-SCCP-instance scope
* this way, every SCCP user knows exactly which SCCP connection identifiers are currently in use between this specific user and the SCCP provider, and it hence can choose any unused ID for a new connection
* right now, the primitive exchange across the SCCP user SAP is synchronous, so there can be no races where the SCCP provider and the SCCP user could chose the same connection ID at the same time. If you want to prepare for some kind of possible future asynchronous, message-queue based SAP, then you could use the highest bit as "allocation flag", e.g. highest bit = 0, allocated by the SCCP provider and highest bit = 1, allocated by SCCP user.
Let me know if you see any problem with above proposal.
Regards, Harald
On Wed, Mar 20, 2019 at 08:22:35AM +0100, Harald Welte wrote:
- don't recycle the SCCP local reference (protocol) from the SCCP connection ID (SAP), but use distinct number spaces for that.
Ah. So the proper solution is to be fine with "collisions" because local reference and SAP conn id are distinct number spaces. Ok, but...
I know you will probably roll your eyes at least once when reading this mail, and I sympathise, but please bear with me so I can figure out what exactly osmo-msc should do about outgoing SAP conn_id...
For me there is still a disconnect in the reasoning.
In short, whoever invents SAP conn ids should invent them for both directions. (Nevermind local-reference, only talking SAP conn ID.)
In long: Let's focus on that last stage alone, as close as it gets to the message consumer:
a) remote peer sends a N-CONNECT. "Things happen" in SCCP, then in the end: libosmo-sccp dispatches me a struct osmo_scu_prim. prim.connect.conn_id contains a number, the SAP connection ID.
b) I send an N-CONNECT. I compose an osmo_scu_prim. I put in prim.connect.conn_id a number, the SAP connection ID. "Things happen" to send SCCP.
If these SAP conn_ids are of the same number space for incoming and outgoing osmo_scu_prim, which I assume, then why not provide the caller of the SAP API, in that first stage that actually dispatches/receives the struct osmo_scu_prim locally, nevermind the SCCP wiring happening further away, with one common API function to determine an unused local SAP conn_id?
[----------osmo-program-----------] SCCP provider SAP API message handler ---------local-ref-----> black --conn_id-> <--------local-ref------ box <-conn_id-- ^ get_unused_sap_conn_id()
Am I getting this picture correctly? (ignoring that currently the SCCP provider is also in the same program, incidentally.)
That layer violating patch of mine was made from an angle of: "this osmo_user_sap API has to know which struct osmo_scu_prim.*.conn_id already exist, nevermind how they are made. Even if we separate local ref and conn_id later, the knowledge about used conn_ids will still be in this first stage, and the caller should still ask the osmo_user_sap API for an unused SAP conn_id instead of iterating its own object lists."
Shouldn't be too hard to separate the SAP conn ID scope from the local-reference scope in libosmo-sccp, if that is needed to allow this in a correct way. Otherwise we only push the mistake into osmo-{bsc,msc} code.
Thanks
~N
-
Harald Welte -
Neels Hofmeyr