gecko/media/mtransport
2013-06-19 19:08:06 +08:00
..
build Bug 906990 - Part 5: Allow logging related to a given candidate pair to be fetched. r=ekr 2013-10-29 10:45:09 -07:00
standalone Bug 930674 - convert VISIBILITY_FLAGS in Makefile.in to NO_VISIBILITY_FLAGS in moz.build. r=mshal 2013-10-24 15:06:19 -04:00
test Bug 902587 - Part 2A: Refactor late-write-checks as client of IO Interposer. r=BenWa 2013-11-05 07:45:20 -05:00
third_party Bug 906990 - Part 5.1: Enable r_log and RLogRingBuffer so logging can be scraped. Also, tweak log levels so the RLogRingBuffer isn't rapidly overwritten by media packet logging. r=ekr 2013-10-29 11:53:44 -07:00
databuffer.h Bug 916187. Part 2. Using the test stun server, write some tests to exercise the checking logic written in 908740. r=abr 2013-09-18 12:36:13 -07:00
dtlsidentity.cpp
dtlsidentity.h
gonk_addrs.cpp
logging.h
m_cpp_utils.h
nr_socket_prsock.cpp Bug 869869 - Part 3, add an IPC implementation of NrSocket, r=ekr. 2013-06-19 19:08:06 +08:00
nr_socket_prsock.h Bug 869869 - Part 3, add an IPC implementation of NrSocket, r=ekr. 2013-06-19 19:08:06 +08:00
nr_timer.cpp
nricectx.cpp Bug 906990 - Part 5.1: Enable r_log and RLogRingBuffer so logging can be scraped. Also, tweak log levels so the RLogRingBuffer isn't rapidly overwritten by media packet logging. r=ekr 2013-10-29 11:53:44 -07:00
nricectx.h Bug 928060: Parse ?transport=[udp|tcp] in TURN uri. r=ehsan 2013-10-18 18:14:21 -04:00
nricemediastream.cpp Back out 1cbb486b4fb7:8e3a17767287 (bug 906990) for leaks 2013-10-28 15:30:11 -07:00
nricemediastream.h Back out 1cbb486b4fb7:8e3a17767287 (bug 906990) for leaks 2013-10-28 15:30:11 -07:00
nriceresolver.cpp
nriceresolver.h
nriceresolverfake.cpp
nriceresolverfake.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
objs.mozbuild Bug 906990 - Part 5: Allow logging related to a given candidate pair to be fetched. r=ekr 2013-10-29 10:45:09 -07:00
README
rlogringbuffer.cpp Bug 934317: Mutex-protect the RLogRingBuffer, since more than one thread is using it. r=jesup 2013-11-04 15:39:51 -08:00
rlogringbuffer.h Bug 934317: Mutex-protect the RLogRingBuffer, since more than one thread is using it. r=jesup 2013-11-04 15:39:51 -08:00
runnable_utils_generated.h
runnable_utils.h
runnable_utils.py
sigslot.h Bug 932420: sigslot.h - #ifdef'ed out unused multi-threading to avoid windows.h, r=jesup 2013-10-29 19:49:34 -04:00
simpletokenbucket.cpp Bug 931186 - Dirt simple token bucket class. r=ekr 2013-10-25 15:15:59 -07:00
simpletokenbucket.h Bug 931186 - Dirt simple token bucket class. r=ekr 2013-10-25 15:15:59 -07:00
transportflow.cpp
transportflow.h Bug 913847 - stop needlessly including nsThreadUtils.h - r=ehsan 2013-09-19 09:54:39 -04:00
transportlayer.cpp Bug 913847 - stop needlessly including nsThreadUtils.h - r=ehsan 2013-09-19 09:54:39 -04:00
transportlayer.h Bug 913847 - stop needlessly including nsThreadUtils.h - r=ehsan 2013-09-19 09:54:39 -04:00
transportlayerdtls.cpp
transportlayerdtls.h
transportlayerice.cpp
transportlayerice.h
transportlayerlog.cpp
transportlayerlog.h
transportlayerloopback.cpp
transportlayerloopback.h
transportlayerprsock.cpp
transportlayerprsock.h

This is a generic media transport system for WebRTC.

The basic model is that you have a TransportFlow which contains a
series of TransportLayers, each of which gets an opportunity to
manipulate data up and down the stack (think SysV STREAMS or a
standard networking stack). You can also address individual
sublayers to manipulate them or to bypass reading and writing
at an upper layer; WebRTC uses this to implement DTLS-SRTP.


DATAFLOW MODEL
Unlike the existing nsSocket I/O system, this is a push rather
than a pull system. Clients of the interface do writes downward
with SendPacket() and receive notification of incoming packets
via callbacks registed via sigslot.h. It is the responsibility
of the bottom layer (or any other layer which needs to reference
external events) to arrange for that somehow; typically by
using nsITimer or the SocketTansportService.

This sort of push model is a much better fit for the demands
of WebRTC, expecially because ICE contexts span multiple
network transports.


THREADING MODEL
There are no thread locks. It is the responsibility of the caller to
arrange that any given TransportLayer/TransportFlow is only
manipulated in one thread at once. One good way to do this is to run
everything on the STS thread. Many of the existing layer implementations
(TransportLayerPrsock, TransportLayerIce, TransportLayerLoopback)
already run on STS so in those cases you must run on STS, though
you can do setup on the main thread and then activate them on the
STS.


EXISTING TRANSPORT LAYERS
The following transport layers are currently implemented:

* DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack
* ICE  -- a wrapper around the nICEr ICE [RFC 5245] stack.
* Prsock -- a wrapper around NSPR sockets
* Loopback -- a loopback IO mechanism
* Logging -- a passthrough that just logs its data

The last three are primarily for debugging.