<p style="white-space: pre-wrap; word-wrap: break-word;">Let me recap the problem space around this patch:</p><ul><li>the IPA multiplex protocol has an arbitrary data+length field for peer identification.</li><li>in osmo-hlr DB, the peer identification is defined as VARCHAR(32), but SQLite does not enforce the length of 32 (it becomes a TEXT field under the hood).</li><li>I think the idea was a decimal number to identify VLR and HLR</li><li>in hlr_subscriber, we use a char {vlr,sgsn}_number[32], i.e. hard limited to 31 chars plus nul, since most code expects nul termination.</li><li>in osmo-hlr cfg and code, we use an arbitrary C string (nul terminated)</li><li>we'd like to be open to a DIAMETER future with an arbitrary blob as identification?</li><li>...with a global title as identification?</li></ul><p style="white-space: pre-wrap; word-wrap: break-word;">The struct osmo_gsup_peer_id came about because many code paths passed a data+length pointer around as arguments, with unclear data ownership issues. I needed to clarify that with a simple self-contained struct that is certain to have no hidden dynamic allocation going on,<br>and which will survive async event handling.</p><p style="white-space: pre-wrap; word-wrap: break-word;">The current state of this patch is attempting to be a universal data type open to all of the above interpretations, which I am unsure about. I don't like very much how convoluted this has become, especially since being this universal is not supported by many code paths.</p><p style="white-space: pre-wrap; word-wrap: break-word;">If we kept it simple and stick to the current actual usage, we would simply enforce all GSUP peer identification to be a nul terminated string of max 31 characters plus a nul.</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">Expanding from that:<br>- Having more length would require adjusting hlr_subscriber's max length.<br>- Having an arbitrary blob would require:<br>  - changing the DB schema<br>  - inventing some way to configure BLOBs in the osmo-hlr.cfg<br>- I am not familiar with how we would tie in a DIAMETER identification.</pre><p style="white-space: pre-wrap; word-wrap: break-word;">If there are any opinions or aspects I missed, I'd be glad to hear them.</p><p><a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16459">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-hlr/+/16459">change 16459</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16459"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-hlr </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Ide9dcdca283ab989240cfc6e53e9211862a199c5 </div>
<div style="display:none"> Gerrit-Change-Number: 16459 </div>
<div style="display:none"> Gerrit-PatchSet: 9 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: osmith <osmith@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 28 Apr 2020 14:11:43 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>