/* * 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. */