Add NOTES, fix end of file lines, and add Repopack config

This commit is contained in:
Caesar Kabalan 2024-10-08 00:24:15 -07:00
parent c3bf86574d
commit 805a09d0b1
No known key found for this signature in database
GPG key ID: DDFEF5FF6CFAB608
6 changed files with 187 additions and 1 deletions

107
.repopackignore Normal file
View file

@ -0,0 +1,107 @@
# VisualSubnetCalc Custom
dist/css/bootstrap.*
src/cloudformation.yaml
# RepoPack Defaults
# Version control
.git/**
.hg/**
.hgignore
.svn/**
# Dependency directories
node_modules/**
**/node_modules/**
bower_components/**
**/bower_components/**
jspm_packages/**
**/jspm_packages/**
vendor/**
.bundle/**
.gradle/**
target/**
# Logs
logs/**
**/*.log
**/npm-debug.log*
**/yarn-debug.log*
**/yarn-error.log*
# Runtime data
pids/**
*.pid
*.seed
*.pid.lock
# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov/**
# Coverage directory used by tools like istanbul
coverage/**
# nyc test coverage
.nyc_output/**
# Grunt intermediate storage
.grunt/**
# node-waf configuration
.lock-wscript
# Compiled binary addons
build/Release/**
# TypeScript v1 declaration files
typings/**
# Optional npm cache directory
**/.npm/**
# Optional eslint cache
.eslintcache
# Optional REPL history
.node_repl_history
# Output of 'npm pack'
*.tgz
# Yarn files
**/.yarn/**
# Yarn Integrity file
**/.yarn-integrity
# dotenv environment variables file
.env
# next.js build output
.next/**
# nuxt.js build output
.nuxt/**
# vuepress build output
.vuepress/dist/**
# Serverless directories
.serverless/**
# FuseBox cache
.fusebox/**
# DynamoDB Local files
.dynamodb/**
# TypeScript output
#dist/**
# OS generated files
**/.DS_Store
**/Thumbs.db
# Editor directories and files
.idea/**
.vscode/**
**/*.swp
**/*.swo
**/*.swn
**/*.bak
# Package manager locks
**/package-lock.json
**/yarn.lock
**/pnpm-lock.yaml
# Build outputs
build/**
out/**
# Temporary files
tmp/**
temp/**
# repopack output
repopack-output.txt
# Essential Python-related entries
**/__pycache__/**
**/*.py[cod]
**/venv/**
**/.venv/**
**/.pytest_cache/**
**/.mypy_cache/**
**/.ipynb_checkpoints/**
**/Pipfile.lock
**/poetry.lock

View file

@ -11,3 +11,4 @@ RUN npm run build
FROM nginx
COPY --from=build /app/dist /usr/share/nginx/html

View file

@ -19,3 +19,4 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

57
NOTES.md Normal file
View file

@ -0,0 +1,57 @@
# Notes
## Efficient Saves
Looks like the most efficient way to store an address is to track the base network (say 10.0.0.0/8) and then represent
all other addresses as offsets from that base network. This way, we can store a subnet as a base network and a mask. The
most efficient way to store this is to store two values:
- The base network offset (0 to 4,294,967,296)
- 0 being the best case, a subnet within the base subnet with the same network address (10.0.0.0/24)
- 255.255.255.255 being the worst case, the last address in 0.0.0.0/0 (unrealistic)
- The mask (0 to 32)
Combine both of these values into a single binary string that is 32+5 bits. Round the storage up to the nearest byte
(40 bits = 5 bytes), padding the remaining bits with 0s, then encode this 5 byte string into a URL-safe base64 string.
Example for 10.0.0.0/8 and representing the network 10.0.15.0/24:
Find the offset:
10.0.0.0 (decimal):
00001010 00000000 00000000 00000000 → 167772160
10.0.15.0 (decimal):
00001010 00000000 00001111 00000000 → 167775232
Offset: 167775232 - 167772160 = 3072
Hmmm, this above works good for close together smaller networks but gets ugly when you're dealing with larger networks
because the offset is huge.
I'm thinking about a coordinate system. Let's say you have a base network of 10.0.0.0/8 and you want to as concisely as
possible represent 10.166.64.0/20. We could represent this as the nth /20 within the /8 and just store N-20, and
probably shorten that even more with the last digit always being base32 for the mask.
If I'm doing my math right you can say a /20 has 4096 addresses.
10.0.0.0 = 167772160
10.166.64.0 = 178667520
178667520 - 167772160 = 10895360
10895360 / 4096 = 2660
Which means 10.166.64.0 is the 2,660th /20 within the /8. You could store this as 2660x20 (inefficient)
You can reverse this 2660x20 from 10.0.0.0/8 by doing the following:
a /21 has 4096 addresses, times the 2660th network is 10895360. Add that to the base network address to get the network
10.0.0.0 = 167772160
167772160 + 10895360 = 178667520
178667520 = 10.166.64.0 then you can tack back on the /20
This has the advantage overall that you're unlikely to store wildly different subnet sizes in the same page. Your "N" in
the "Nth" subnet is likely to be very small. You're more likely to store the Nth /24 in a /20 than you are a /20 in an
/8. So the numbers will mostly be 1-2 digits, rarely 3 digits, and almost never 4 digits as depicted above.
I then for efficienty I could use this format:
`[Nth Network as Integer][Network Size as Base32]`
So lets say you're wanting to represent the 0th /24 in a /20 you would represent it as `00`, always knowing the last
digit is the network size. Or the 0th /32 would be `07` (32 in base32 is 7). or the 5th /28 would be `54`.

View file

@ -105,3 +105,4 @@ Split icon made by [Freepik](https://www.flaticon.com/authors/freepik) from [Fla
## License
Visual Subnet Calculator is released under the [MIT License](https://opensource.org/licenses/MIT)

19
repopack.config.json Normal file
View file

@ -0,0 +1,19 @@
{
"output": {
"filePath": "repopack-output.txt",
"style": "xml",
"removeComments": false,
"removeEmptyLines": false,
"topFilesLength": 5,
"showLineNumbers": false
},
"include": [],
"ignore": {
"useGitignore": true,
"useDefaultPatterns": false,
"customPatterns": []
},
"security": {
"enableSecurityCheck": true
}
}