doc/developer/WiFiDogProtocol_V2

Version 1 (modified by benoitg, 14 years ago)

Dump my notes

Main contributors: Benoit Grégoire, Philippe April Last modified: 2008-03-21

This page documents the design effort for designing version two of the wifidog protocol specification. While it will eventually turn into a structured specification, currently,

Wire protocol

Response format

It is desirable to have the following features in the wire protocol:

  • Compact representation (bandwidth is NOT cheap when serving a distributed network)
  • Human readable
  • Fast and small parsers available for C and PHP, and ideally multiple other languages
  • Suitable for sharing parser and format with the configuration file
  • Suitable for cleanly representing trees (like the list of auth servers

That pretty much leaves only two options: YAML and XML, with YAML matching them more closely.

Request format

It is beyond desirable to have to following with request format:

  • More than one operation per http request (for example, update statistics for more than one user)
  • Keep the http transport, as it allows us full NAT and transparent proxy resistance

Some of the requirements above do not lend itself well to a RESTFull Resource oriented architecture (ROA). However, keeping the current format (GET parameters) limit us, in practice, to a single list of tag-value pairs. Even if one could, in theory, put an action=whatever in the middle of the list and have the protocol decree that every following parameters (until the next action) is to be a parameter of that action, that would utterly confuse most web servers and frameworks.

So POSTing the parameters may have to be considered, in which case the same format as the response should be used, for obvious reasons.

Functionnal Requirements

  • Allow some general configuration changes to be sent by the auth server.
  • Allow non web-based MAC auth
  • Allow non connection based MAC auth
  • Allow per-connection firewall policies
  • Allow per-connection bandwidth management, not limited to set amounts
  • Many more....

Actions

NOOP

Basically there only for gateway heartbeating. A min delay between operations would be specified, and if this delay is reached before an actual operation has to be performed, a NOOP is sent.

AUTH_VERIFY

STATS_UPDATE