/*
* Rationale:
* this code implements the en50221 transport layer.
* The transport layer is created with gst_dvb_cam_transport_new and destroyed
* with gst_dvb_cam_transport_destroy.
*
* The transport layer is connection oriented.
* A connection can be requested by the module but in any case it's always
* created by the host.
* A connection is created with gst_dvb_cam_transport_create_connection () and
* closed with gst_dvb_cam_transport_delete_connection (). When the module
* requests a connection, the transport->connection_requested callback is
* invoked.
*
* On a connection, transport protocol data units (TPDUs) can be written and
* read. A TPDU is a Tag-Lenght-Value object, meaning that each TPDU is
* identified by a tag and has a lenght-prefixed value. TPDUs can be classified
* in two classes: control TPDUs, which are issued by both the host and the
* module to control the connection and data TPDUs, which carry data produced
* by the host or the module.
* The module never sends TPDUs first, it only sends them in response to host
* TPDUs.
* Each host TPDU receives at least one response TPDU from the module. The last
* TPDU of every response TPDU sequence from the module is a control TPDU that
* signals whether the module has data TPDUs to send or not. The value of this
* TPDU can be accessed with gst_dvb_cam_transport_has_data (). To always get an
* updated value for this TPDU, gst_dvb_cam_transport_poll_has_data () can be
* used.
*
* Data TPDUs are written with gst_dvb_cam_transport_write_data. Segmentation is
* done in the link layer. TODO: figure out if there's a maximum TPDU size.
* To read data TPDUs gst_dvb_cam_read_data is used.
*
* Also the implementation exposes some low levels calls to read and write TPDUs
* directly on a connection:
*
* gst_dvb_cam_transport_tpdu_read_header returns the header of a TPDU (ie. its
* tag and length) and then gst_dvb_cam_transport_read_tpdu_value, that reads
* the body of the TPDU.
* gst_dvb_cam_transport_tpdu_write writes a TPDU.
*/