phuedx/pinc

A network connection conditioner for a handful of low-end devices in my home office

pinc's Issues

Determine device profile state from tc output

Currently, the profile service keeps track of state via an internal store. The store is mistakenly referred to as a cache and while there's definitely a write-through mechanism in place, there's no corresponding read from tc when the cache goes stale. Indeed, the "cache" is never considered stale!

It should be fairly easy to parse out the profiles assigned to devices from the output of tc filter show dev <interface>, given that the flow IDs of those profiles are known ahead of time and are mapped easily (see getFlowID in src/server/profiles.js).

Share flow ids between the node process and the setup script

From irc review:

I think it is worth sharing the profile ids between the node process and the bash script somehow https://github.com/phuedx/micro-device-lab/blob/dev/src/profiles.js#L8-L13 so that you don't have to implicitly keep them in sync the ids with the setup script ones.

I think the easiest way would be a script that exports the profiles and ids as environment variables, such script would get called at the beginning of script/setup and in package.json when npm starting:

  "scripts": {
    "start": "./scripts/env && node index.js"
  }

 cd "$(dirname "$0")/.."

+script/env
 script/bootstrap

Not exactly sure about that script/env would set. I know there's bash dictionaries but I'm not sure how those would be read in node with process.env.

Is there an easy way to load a JSON file into a bash script?

Any opinions?

Conditioning not taking effect

I have a Raspberry Pi 3 (built-in wifi), and I've gotten as far as configuring it as an access point, running the PiNC service, and looking at the web interface.

However, when I actually enable throttling for a connected device, it doesn't seem to have any effect. The connection quality from the target device appears the same. In the PiNC web interface, the throttling icon is shown next to the device, but when I refresh the page, the icon goes away and the device is no longer shown as throttled.

Remove exec abstraction

Currently, src/server/exec.js is relied upon to abstract away whether or not to shell out the tc commands from the profiles service. When in dev mode, require('/path/to/exec').exec( '...' ) is a NOP.

If we were to separate out the caching part of the profiles service from the tc part, define an interface and its null implementation, then we can safely remove the abstraction by composing these new services:

const profilesService = require('...')
const cachingProfilesService = require('...')
const nullProfilesService = require('...')

const profileService = cachingProfilesService( IS_PROD ? profilesService : nullProfilesService )

Research and document other network throttling profiles

• Latency and Jitter in Mobile Networks from Ilya Grigork's High Performance Browser Networking.
• WebPageTest's connectivity.ini.sample

Rename project to Pi Network Conditioner

Ronseal.

Naming things is difficult. When this project was first started, I thought "Hey! I have a small device lab in my office! That's a micro device lab!" Alas, this project isn't that. It's a Raspberry Pi Network Conditioner… or PiNC!

Configure download and upload bandwidth separately

As I commented on #5:

Google Chrome/Chromium's network throttling profiles now have download and upload bandwidth configured separately, thus µDL should configure download and upload bandwidth separately too.

Add a /profiles endpoint

I think a /profiles endpoint that returned the profiles with the network info would be very useful for the UI too. Example response:

  [
    {
      name: "2G",
      bandwidth: "50",
      rtt: "500"
    },
    // ...
  ]

Document limitations of emulation

Provided that the profiles are based on documentation – from carriers, hopefully – or research, then, like Google Chrome's Network Conditioner, this can be a useful emulation. However, it remains an emulation.

Add descriptions to profiles

Ronseal.

… and expose them in the user interface.

Existing filters aren't deleted

If a profile has previously been set, then the existing filter (created in profileService#setProfile) needs to be removed.