12 Mar
2019
12 Mar
'19
7:36 a.m.
On Mon, Mar 11, 2019 at 09:48:17PM +0100, Harald Welte wrote:
Either way there is some RUA id and hnbgw just uses that 1:1 for outgoing RANAP
connections. There aren't any incoming ones from RANAP, at least yet. So when I
tried to copy hngbw's way of coughing up an id I was disappointed.
~N
The SCCP User SAP is modelled strictly after the ITU
specs. Always
imagine yourself in a situation where the SCCP user and SCCP provider
are running in different processes and they don't have access to each
others's state - and all they can exchange are the SCCP User SAP
primitives in some serialized form.
So the point is that this next_id used in below patch could be in a different
process than the one composing the N_CONNECT prim in need to invent the
conn_id?
How can individual users then possibly avoid treading all over each others
scu_prim.u.*.conn_id numbers?? Assign a unique part of the number space to each
user or something?
So as long as we don't separate into different processes we're fine?
To me personally, it feels like we should be done separating by now :P
Using the current single-process status quo, I wrote in code what I mean.
Is this bad in any way?
http://git.osmocom.org/libosmo-sccp/commit/?h=neels/conn_id&id=9e735cc5…
The point is that when a CONNECT comes in from the remote side, this bit of
code picks a conn_id that becomes visible in the scu_prim.u.connect.conn_id.
The reverse way, sending a CONNECT from here to the remote side, why not use
the exact same mechanism to cough up a prim.u.connect.conn_id?
BTW, what osmo-bsc does (picking any conn_id it isn't currently using) also
wouldn't work if there were multiple users for an SCCP provider in separate
processes. How does existing separate-process software solve this?
(In above patch I also introduced the possibility to exhaust the conn_id number
space gracefully, however far fetched and completely unrealistic that may be.)
This patch works for osmo-msc in ttcn3-msc-test for inter-BSC Handover.
What kind of object would the SCCP provider use
to keep track of allocated IDs
The one in above patch is struct sccp_connection from sccp_scoc.c
for which there is no connection yet, as
the N-CONNECT.req was not yet received?
(yes, also a tricky one in allocating a new RAN connection in osmo-msc.)
In current single-process mode, sccp_scoc.c just inst->next_id++ and hence will
only deal out the same ID 0xffffffff times later, regardless of the caller
actually using them / of struct sccp_connection created or not.
The current situation is not great. After all,
theoretically there
could be an incoming new SCCP connection for which the provider choses
the same ID that the user at the same time choses for a new outbound
connection -> boom.
Currently, in a single process, sccp_scoc.c increases the inst->next_id for
outgoing and for incoming requests, which is synchronous, and there is no
problem. Would be if becoming asynchronous though.
BTW, again looking at current osmo-bsc: since osmo-bsc invents its own new IDs
without doing inst->next_id++, the next_id doesn't cycle so nicely, so possibly
an outgoing conn_id that has just this instant stopped being used might be used
right away again for an incoming N_CONNECT, because osmo-bsc didn't increment
the inst->next_id. Or in other words, every Handover Request from the MSC will
start from id 0 while Complete-L3 from BSC have already moved up past 0 before.
Not illegal as such, but still would be nicer to have some grace period before
re-using existing numbers, if for nothing else then for reading log files. So
while we're having the provider in the same process, it might be nicer to also
use above patch in osmo-bsc, to ensure the next id is always larger than the
previous ones.
...unless you're completely against this kind of thing.
Though there isn't really an alternative solution right now AFAICT.
hnbgw just
uses 1:1 the same conn_id from RUA to RANAP and thus doesn't invent new ones
Now I'm confused. RUA isn't running over SCCP, right?