gecko/media/mtransport
Mike Hommey d667f4bb59 Bug 1077148 part 4 - Add and use new moz.build templates for Gecko programs and libraries. r=gps
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.

Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.

Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
2014-10-30 13:06:12 +09:00
..
build Bug 806819 - Part 4: Add files that were excluded from unified builds back in. r=ehsan 2014-10-08 13:19:14 -07:00
standalone Bug 806819 - Part 4: Add files that were excluded from unified builds back in. r=ehsan 2014-10-08 13:19:14 -07:00
test Bug 1077148 part 4 - Add and use new moz.build templates for Gecko programs and libraries. r=gps 2014-10-30 13:06:12 +09:00
third_party Bug 1027350 - Allow loopback addresses for ICE. r=bwc 2014-06-22 15:11:48 -07:00
databuffer.h
dtlsidentity.cpp
dtlsidentity.h
gonk_addrs.cpp
logging.h Bug 806819 - Part 3: Remove redundant FORCE_PR_LOG entries. r=ehsan 2014-10-08 13:17:32 -07:00
m_cpp_utils.h
nr_socket_prsock.cpp Bug 1053454 - disable remote TCP socket creation before TURN-TCP is e10s ready. r=ekr. 2014-09-03 11:02:11 +08:00
nr_socket_prsock.h
nr_timer.cpp
nricectx.cpp Bug 1027350 - Allow loopback addresses for ICE. r=bwc 2014-06-22 15:11:48 -07:00
nricectx.h Bug 1027350 - Allow loopback addresses for ICE. r=bwc 2014-06-22 15:11:48 -07:00
nricemediastream.cpp Bug 991037 - Part 2: Convert over to full trickle, which allows some simplification of code, and makes the following work much easier. r=mt 2014-08-07 10:20:26 -07:00
nricemediastream.h Bug 991037 - Part 2: Convert over to full trickle, which allows some simplification of code, and makes the following work much easier. r=mt 2014-08-07 10:20:26 -07:00
nriceresolver.cpp
nriceresolver.h
nriceresolverfake.cpp
nriceresolverfake.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
objs.mozbuild
README
rlogringbuffer.cpp
rlogringbuffer.h
runnable_utils_generated.h
runnable_utils.h
runnable_utils.py
sigslot.h
simpletokenbucket.cpp
simpletokenbucket.h
stun_udp_socket_filter.cpp
stun_udp_socket_filter.h
transportflow.cpp
transportflow.h
transportlayer.cpp
transportlayer.h
transportlayerdtls.cpp Bug 1058331: Plug a leak in TransportLayerDtls::Setup, and remove a suppression. r=mt 2014-08-25 17:15:07 -07:00
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.