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 Wed, Nov 25, 2015 at 09:05:40PM +0100, Holger Freyther wrote: > > + /* The TEI numbers will simply wrap and be reused, which will work out > > + * in practice. Problems would arise if one given peer maintained the > > + * same TEI for a time long enough for the TEI nr map to wrap an entire > > + * uint32_t; if a new TEI were mapped every second, this would take > > + * more than 100 years (in which a single given TEI must not time out) > > + * to cause a problem. */ > > Unless performance matters I am not for probalistic correct, specially not in the > beginning of a new piece of software. "Modern" smartphones will open a PDP > context very early and they live for a potentially long time (until you reboot your > phone or such). The TEI space will exhaust even slower, then :) The more *new* PDP contexts are created, the faster the pool will wrap. > So I would prefer to check if a TEI is used (at least the number should be random) > before using it. So even if the assignment is not random right now I would still > prefer the check if it is assigned or not. So I should iterate all tunnels to ensure a new TEI is unused. I'm anyway iterating all tunnels to detect a peer reusing a TEI it had sent before, also checking against the mapped TEI is easy to add. > E.g. a unit test that exhausts the entire number space should be feasible. Really? 4.294.967.295 TEI mappings?? Thats 4*sizeof(mapping) gigabytes and might need special memory model options to work, and the testing machine needs that many gigs of ram and will take quite a while: O(n²)... Probably easier to manually assign a given TEI and make the pool return that TEI next. Is your suggestion to shrink the TEI space? And next, what about sequence numbers? The space is much smaller (65.536 values), and expires after 30 seconds. To me, it is much more realistic that we receive 66.000 messages with distinct sequence numbers within the space of 30 seconds, than that a given TEI will remain in use for more than 100 years in a place where a new subscriber shows up every single second. So, verifying that a *sequence number* is unused seems to be way more critical than the TEI check. Which touches the optimization topic. Currently gtphub will have to iterate everything all the time. To optimize, one way would be to list tunnels at the peers they associate with, but if gtphub is used as proxy for a single peer, that has exactly zero effect. So some way of hash map might be more useful. But gtphub wants several different views, i.e. sometimes it wants to find an original TEI, sometimes a mapped TEI, sometimes from SGSN and sometimes from GGSN side, and sometimes it wants to find all tunnels for a given peer. So, to optimize we'd want a couple of separate hash maps hashing one and the same list from different angles. I'd be glad for any ideas, or hints at existing Osmocom API. But, unless told otherwise, I simply won't bother about optimization for now... ~Neels -- - Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151126/1fc5515e/attachment.bin>