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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Mon, Mar 11, 2019 at 09:48:17PM +0100, Harald Welte wrote: > 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=9e735cc537dfe267aa399f58b3d79f07e590d12f 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? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190312/6de321f5/attachment.bin>