Attention is currently required from: neels, pespin.
1 comment:
File src/osmo-hnbgw/context_map_sccp.c:
tx_sccp_df1(fi, ranap_msg);
tx_sccp_rlsd(fi);
ok. i'm still a bit unclear, is this about only tx_sccp_rlsd() or also the other one?
Any function that implies transmitting a certain packet is named wrong.
> in my POV both functions already have the best names -- they both transmit actual SCCP packets on the wire,
they do not, which is why they are mis-nomers.
by asking the SCCP user sap. So may I ask reviewers to just tell me which function(s) to rename to exactly what and I can do that.
The point is that you are *not* requesting the SCCP stack/provider to transmit a certain packet. You are requesting the SCCP stack to terminate a connection. Depending on the internal state of the SCCP stack, and the protocol specification, this *may* trigger a RLSD packet. So unless you reviewed the SCCP state meachines of Q.714 in the last detail, and can prove that no matter what, there will always be a RLSD, the name is wrong.
When I wrote the original comment, I stated "I personally don't know the SCCP CO state machines sufficiently off my head". I now did, and it confirms my point all along,
A cursory glance of e.g. scoc_fsm_conn_pend_out() shows that SCOC_E_SCU_N_DISC_REQ in this case does not trigger the generation of a RLSD message. Or if you check scoc_fsm_conn_pend_in(), then a SCOC_E_SCU_N_DISC_REQ triggers a SUA CORE packet (which is a CREF in SCCP), and not a RLSD.
The SCCP user has no way to send individual protocol messages. This is what protocol stacks are all about. If we wanted the user to implement all the nitty gritty details of SCCP internally, then the user could transmit low-level SCCP packets itself. But it doesn't. It's just a user of the SCCP SAP ("API"), and that API has high-level primitives and not low-level commands to trigger transmission of certain packets.
Just like you call close() on a TCP socket. That's what you care about. You don't care about (nor know) if the TCP stack does this with a FIN packet, RST packet or in whatever other magic way.
In every case that would happen in a separate patch. If there's no opposition, I'm going to click on 'Resolved' here, from the perspective of review on the changes of *this* patch.
agreed.
To view, visit change 32915. To unsubscribe, or for help writing mail filters, visit settings.