routing by packet lookup #257
Merged
Conversation
This file contains 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
do not check how many requests have been sent until the multi-buy function has been called enough times that it could be more than what we expect.
When it packet comes into routing... 1. It's never been seen before and we need to figure out the routing information for it. 2. We've seen it before, and have not yet determined the routing, in which case it get's queued. 3. We've seen it before, and already know what to do.
SKF tables are not sets with no timing information. We can do direct inserts and deletes for greater performance.
SKF are unique in their route tables since the last_used key has been removed. If more than one route has an applicable skf, let's send to it.
every 15 seconds, anything older than 2 minutes will be cleaned out.
jadeallenx
reviewed
Sep 14, 2023
macpie
reviewed
Sep 14, 2023
macpie
reviewed
Sep 14, 2023
macpie
reviewed
Sep 14, 2023
Do not let more than 1 cleanup routine start. Check if the current cleanup is registered, and bail if there's another PID claiming to be the cleanup.
when more than one packet is told to establish routing, the first will get the lock and continue. The second will see it's not the first entry, and go back to looking up routing again. Most likely to queue itself.
michaeldjeffrey
force-pushed
the
mj/packet-lookup
branch
from
2b8d3e3
to
c1f34dc
Compare
inserts and deletes are from a set table with a known key, not an ordered_set with a timestamp as the key.
michaeldjeffrey
force-pushed
the
mj/packet-lookup
branch
from
abf15da
to
2a55845
Compare
|
The current largest DevAddr used has ~13.5k Session Key Filters. Providing a packet that will never match any of the SKFs. (running with a single core locally).
|
macpie
approved these changes
Sep 18, 2023
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.
This PR changes the way packets get their routing determined, for the purpose of having more freedom in how we store SessionKey Filters.
The when of packets
The first time a packet is see, we take a lock on the phash and start finding if it's routable.
Any packets that come in during that time will queue themselves.
Once the routing is figured out, the initial packet, and all the queued packets are routed, and the routing information is put into ETS.
Any packet coming along after routing has been determined will immediately retrieve it's routes.
Multi-buy is always checked.
But there's a lot of changes to SKF storage...
The last_used timestamp for an SKF is removed. Worst case scenario is the applicable SKF is at the end of an ETS table, but that lookup is only done one time per hash.
This means we can keep SKF unique by session_key, and delete in constant time.
Other things of note