-
Notifications
You must be signed in to change notification settings - Fork 3
Encoding
Encoding
** NEED IMAGE HERE **
Certain encoding schemes are suited for higher data rates than others. For instance, the URL encoding scheme is only good for low data rate transactions, as it can only encode on the order of 40 bytes per frame. Images, on the other hand, can encode significantly more data, and, as such, should be used for higher data rates.
The data rate at which data is being sent out will need to be calculated. This can be done in a multitude of ways, but, for htpt, FILL IN DATA RATE CALCULATION HERE
Based upon the data rate, an initial method for encoding will be chosen.
Timing needs to be varied. Inter-frame timing will be varied by choosing a random time between 50ms and 1 second to accumulate data for. This is to keep the browsing that is being masked to still appear to be interactive, if a bit sluggish.
Similarly, a data segment size will be chosen, based upon the information provided by each of the Encoding Modules. That is, if htpt has chosen the URL encoding scheme for low bit rate traffic, and the URL Encoding Module has stated that it is good for frames up to 1000 bytes, a random number around 1000 bytes will be chosen (+/- 25% of maximum encoding value).
Data from the Tor process will be buffered for the chosen time period or until the chosen segment size has been reached, whichever comes first.
If the time period is hit before the chosen segment size, the data encoding scheme may be reevaluated. For instance, if the chosen encoding scheme was bitmap, and bitmaps are for defined as appropriate for 10KB to 3MB, but only 1KB of data was buffered, the encoding scheme could be changed.
This would have some randomness to it as well: it should not be deterministic as to whether or not the encoding scheme is changed every time.
Once the data buffer exists, the data is sent to the chosen Encoding Module. That module then encodes it, attaches sequence numbers, then sends the data to the peer.