Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
I'm sorry; we don't have anything against including this, but this iteration has had a lot of merging conflicts, and this is going to add more, so we wish to postpone it to version 3.1.6.
referenced this pull request
Jun 25, 2014
By the way:
I just opened #100.
A BIB entry's IPv4 address always comes from the IPv4 pool.
When an element from a pool is removed, its BIB and session entries are no longer useful. Up until Jool 3.1.4, these orphan elements would not be removed from the database until they expired; with #65 we've been working on a different model where the destruction of an element from the pool immediately triggers the destruction of its BIB and session entries.
When you call your implementation "naive", I assume that you mean that flushing a pool doesn't cascade to the rest of the database. We're planning to remove this "naivety".
Does this somehow conflict with your use cases?
One thing you might want to keep in mind is that, if the destruction of a BIB or session entry fails (eg. because some other thread is using it at the same time), Jool will refuse to remove the respective element from the pool and the userspace application will ask the user to try again. That is, this cascade business adds a somewhat maybe likely chance of failure when Jool is under heavy traffic.
Feel free to ask back if I've failed to explain something in a satisfactory manner.
Yes, your assumption about "naivety" is correct.