michael@0: This is a generic media transport system for WebRTC.
michael@0: 
michael@0: The basic model is that you have a TransportFlow which contains a
michael@0: series of TransportLayers, each of which gets an opportunity to
michael@0: manipulate data up and down the stack (think SysV STREAMS or a
michael@0: standard networking stack). You can also address individual
michael@0: sublayers to manipulate them or to bypass reading and writing
michael@0: at an upper layer; WebRTC uses this to implement DTLS-SRTP.
michael@0: 
michael@0: 
michael@0: DATAFLOW MODEL
michael@0: Unlike the existing nsSocket I/O system, this is a push rather
michael@0: than a pull system. Clients of the interface do writes downward
michael@0: with SendPacket() and receive notification of incoming packets
michael@0: via callbacks registed via sigslot.h. It is the responsibility
michael@0: of the bottom layer (or any other layer which needs to reference
michael@0: external events) to arrange for that somehow; typically by
michael@0: using nsITimer or the SocketTansportService.
michael@0: 
michael@0: This sort of push model is a much better fit for the demands
michael@0: of WebRTC, expecially because ICE contexts span multiple
michael@0: network transports.
michael@0: 
michael@0: 
michael@0: THREADING MODEL
michael@0: There are no thread locks. It is the responsibility of the caller to
michael@0: arrange that any given TransportLayer/TransportFlow is only
michael@0: manipulated in one thread at once. One good way to do this is to run
michael@0: everything on the STS thread. Many of the existing layer implementations
michael@0: (TransportLayerPrsock, TransportLayerIce, TransportLayerLoopback)
michael@0: already run on STS so in those cases you must run on STS, though
michael@0: you can do setup on the main thread and then activate them on the
michael@0: STS.
michael@0: 
michael@0: 
michael@0: EXISTING TRANSPORT LAYERS
michael@0: The following transport layers are currently implemented:
michael@0: 
michael@0: * DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack
michael@0: * ICE  -- a wrapper around the nICEr ICE [RFC 5245] stack.
michael@0: * Prsock -- a wrapper around NSPR sockets
michael@0: * Loopback -- a loopback IO mechanism
michael@0: * Logging -- a passthrough that just logs its data
michael@0: 
michael@0: The last three are primarily for debugging.
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: 
michael@0: