Cellular: Preventing Socket ID assignment until actual socket creation at the modem #10639
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
May 22, 2019 23:43
Local modem ip stacks vary in their implementations and the way of working. Some of the modems may not open a socket until an IP context is assigned. That's why we came up with a container that stores addresses of any CellularSocket instances created on-demand by the application. When the application requests opening a socket we store allocate and store the premitive in the container however actual socket creation at the modem may happen at a later stage, e.g., a call to send_to() may result in actual opening of a socket. That's why we must not assign socket ids in the CellularSocket object during construction. It must happen when actual socket is opened and is alive. Another implication of the previous model is that we may have multiple sockets created in our container but the actual socket ids are not assigned yet, so we cannot directly map the socket id to the container indices which has been happening previously. To solve this issue we have promoted the AT_CellularStac::find_socket_index(...) method to be a protected method rather than being private so that the children can use the method to determine if the given index in the container corrsponds to the assigned socket id or not. We have given up on the socket->created flag and the whole decision making to actually open a socket on the modem happens on the basis of a valid socket being assigned or not.
Socket ids will be assigned in the create_socket_impl(...) method. This is the point where an actual socket creation at the modem takes place.
Changes introduced to accomodate the socket id assignment upon actual creation of the socket at the modem.
Changes to accomodate socket id assignment upon actual creation of the socket at the modem.
This modem is a special case. It uses a given socket ID value rather than providing one. A naive solution here would be to directly map the index of a CellularSocket object in the CellularSocket container. But considering the case where there are multiple sockets being opened (some sockets being already created at the modem and some yet not created), direct mapping to indices will not work. As it can happen that the CellularSocket object is allocated but the socket id is not assigned yet as it is not actually created on the modem. In such a case, we check the container and assign the socket id from the pool if an empty slot was found.
Changes to accomodate socket id assigment upon actual creation of the socket at the modem.
|
@AriParkkila, thank you for your changes. |
0xc0170
approved these changes
May 23, 2019
|
CI started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR was moved from #10431.
Local modem ip stacks vary in their implementations and the way of
working. Some of the modems may not open a socket until an IP context is
assigned. That's why we came up with a container that stores addresses of
any CellularSocket instances created on-demand by the application. When
the application requests opening a socket we allocate and store the
primitive in the container however actual socket creation at the modem
may happen at a later stage, e.g., a call to send_to() may result in
actual opening of a socket.
That's why we must not assign socket ids in the CellularSocket object
during construction. It must happen when actual socket is opened and is
alive.
Another implication of the previous model is that we may have multiple
sockets created in our container but the actual socket ids are not
assigned yet, so we cannot directly map the socket id to the container
indices which has been happening previously.
To solve this issue we have promoted the AT_CellularStack::find_socket_index(...) method
to be a protected method rather than being private so that the children
can use the method to determine if the given index in the container
corresponds to the assigned socket id or not.
We have given up on the socket->created flag and the whole decision
making to actually open a socket on the modem happens on the basis of a
valid socket id being assigned or not.
Pull request type
Reviewers
Release Notes