media/mtransport/README@97036ab72558 (annotated)
media/mtransport/README
Tue, 06 Jan 2015 21:39:09 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 06 Jan 2015 21:39:09 +0100
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
- permissions
- -rw-r--r--
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
| michael@0 | 1 | This is a generic media transport system for WebRTC. |
| michael@0 | 2 | |
| michael@0 | 3 | The basic model is that you have a TransportFlow which contains a |
| michael@0 | 4 | series of TransportLayers, each of which gets an opportunity to |
| michael@0 | 5 | manipulate data up and down the stack (think SysV STREAMS or a |
| michael@0 | 6 | standard networking stack). You can also address individual |
| michael@0 | 7 | sublayers to manipulate them or to bypass reading and writing |
| michael@0 | 8 | at an upper layer; WebRTC uses this to implement DTLS-SRTP. |
| michael@0 | 9 | |
| michael@0 | 10 | |
| michael@0 | 11 | DATAFLOW MODEL |
| michael@0 | 12 | Unlike the existing nsSocket I/O system, this is a push rather |
| michael@0 | 13 | than a pull system. Clients of the interface do writes downward |
| michael@0 | 14 | with SendPacket() and receive notification of incoming packets |
| michael@0 | 15 | via callbacks registed via sigslot.h. It is the responsibility |
| michael@0 | 16 | of the bottom layer (or any other layer which needs to reference |
| michael@0 | 17 | external events) to arrange for that somehow; typically by |
| michael@0 | 18 | using nsITimer or the SocketTansportService. |
| michael@0 | 19 | |
| michael@0 | 20 | This sort of push model is a much better fit for the demands |
| michael@0 | 21 | of WebRTC, expecially because ICE contexts span multiple |
| michael@0 | 22 | network transports. |
| michael@0 | 23 | |
| michael@0 | 24 | |
| michael@0 | 25 | THREADING MODEL |
| michael@0 | 26 | There are no thread locks. It is the responsibility of the caller to |
| michael@0 | 27 | arrange that any given TransportLayer/TransportFlow is only |
| michael@0 | 28 | manipulated in one thread at once. One good way to do this is to run |
| michael@0 | 29 | everything on the STS thread. Many of the existing layer implementations |
| michael@0 | 30 | (TransportLayerPrsock, TransportLayerIce, TransportLayerLoopback) |
| michael@0 | 31 | already run on STS so in those cases you must run on STS, though |
| michael@0 | 32 | you can do setup on the main thread and then activate them on the |
| michael@0 | 33 | STS. |
| michael@0 | 34 | |
| michael@0 | 35 | |
| michael@0 | 36 | EXISTING TRANSPORT LAYERS |
| michael@0 | 37 | The following transport layers are currently implemented: |
| michael@0 | 38 | |
| michael@0 | 39 | * DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack |
| michael@0 | 40 | * ICE -- a wrapper around the nICEr ICE [RFC 5245] stack. |
| michael@0 | 41 | * Prsock -- a wrapper around NSPR sockets |
| michael@0 | 42 | * Loopback -- a loopback IO mechanism |
| michael@0 | 43 | * Logging -- a passthrough that just logs its data |
| michael@0 | 44 | |
| michael@0 | 45 | The last three are primarily for debugging. |
| michael@0 | 46 | |
| michael@0 | 47 | |
| michael@0 | 48 | |
| michael@0 | 49 | |
| michael@0 | 50 | |
| michael@0 | 51 | |
| michael@0 | 52 | |
| michael@0 | 53 | |
| michael@0 | 54 | |
| michael@0 | 55 | |
| michael@0 | 56 | |
| michael@0 | 57 | |
| michael@0 | 58 | |
| michael@0 | 59 |
