gecko/media/mtransport
2014-06-04 17:21:59 -07:00
..
build
standalone
test Bug 1004530 - Part 3: Unit test that verifies that new pairs will start when local gather happens after all preceding pairs have failed, provided the grace period has not elapsed. Also a couple more tests that use a new test-case feature. 2014-06-04 17:21:59 -07:00
third_party Bug 1004530 - Part 1: Allow a grace period for trickle candidates to arrive when all candidate pairs have failed. r=drno, r=ekr 2014-05-01 14:07:54 -07:00
databuffer.h
dtlsidentity.cpp
dtlsidentity.h
gonk_addrs.cpp
logging.h
m_cpp_utils.h
nr_socket_prsock.cpp Bug 891551 - Part 2: (Upliftable) Fix bugs where PR_WOULD_BLOCK_ERROR (or, in some cases, PR_NOT_CONNECTED_ERROR while a TCP socket was connecting) would cause sockets to be abandoned for no good reason (see also bug 985493 and 1001671). r=bwc 2014-05-02 10:49:00 -07:00
nr_socket_prsock.h Bug 1012999: When STUN global rate limit is exceeded, record this in telemetry. r=ekr 2014-05-19 19:16:38 -07:00
nr_timer.cpp Bug 900908 - Part 3: Change uses of numbered macros in nsIClassInfoImpl.h/nsISupportsImpl.h to the variadic variants. r=froydnj 2014-04-27 03:06:00 -04:00
nricectx.cpp Bug 1004530 - Part 1: Allow a grace period for trickle candidates to arrive when all candidate pairs have failed. r=drno, r=ekr 2014-05-01 14:07:54 -07:00
nricectx.h Bug 942188 - Added parsing of ice-lite attribute and start ice checks as controlling if peer is ice-lite. r=abr 2014-05-16 01:32:00 -05:00
nricemediastream.cpp
nricemediastream.h
nriceresolver.cpp Bug 900908 - Part 3: Change uses of numbered macros in nsIClassInfoImpl.h/nsISupportsImpl.h to the variadic variants. r=froydnj 2014-04-27 03:06:00 -04:00
nriceresolver.h
nriceresolverfake.cpp
nriceresolverfake.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
objs.mozbuild
README
rlogringbuffer.cpp
rlogringbuffer.h
runnable_utils_generated.h Bug 968803 - part 2 - statically type runnable classes that return a result; r=ekr 2014-02-06 10:21:55 -05:00
runnable_utils.h Bug 968803 - part 2 - statically type runnable classes that return a result; r=ekr 2014-02-06 10:21:55 -05:00
runnable_utils.py Bug 968803 - part 2 - statically type runnable classes that return a result; r=ekr 2014-02-06 10:21:55 -05:00
sigslot.h
simpletokenbucket.cpp
simpletokenbucket.h
stun_udp_socket_filter.cpp Bug 900908 - Part 3: Change uses of numbered macros in nsIClassInfoImpl.h/nsISupportsImpl.h to the variadic variants. r=froydnj 2014-04-27 03:06:00 -04:00
stun_udp_socket_filter.h
transportflow.cpp
transportflow.h
transportlayer.cpp
transportlayer.h
transportlayerdtls.cpp Bug 1017755 - Make DTLS 'would have blocked' messages less aggressive r=jesup 2014-05-30 20:02:36 -05:00
transportlayerdtls.h
transportlayerice.cpp
transportlayerice.h
transportlayerlog.cpp
transportlayerlog.h
transportlayerloopback.cpp Bug 900908 - Part 3: Change uses of numbered macros in nsIClassInfoImpl.h/nsISupportsImpl.h to the variadic variants. r=froydnj 2014-04-27 03:06:00 -04:00
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.