Protocol specification

This document describes transmission protocol between repository (server) and CCExtractor (client)

Client communicates with the server by sending packets of arbitrary length. In the source code they are called blocks, for some unknown reason :) These packets have the following syntax:

  1. 1 byte – Control command number – defined protocol constant that represents packet's data
  2. 10 bytes – Packet's data length (N) – string with decimal number >= 0 with leading zeroes that contains the size of packet payload.
  3. N bytes – packet payload – packets' payload data
  4. 2 bytes – \r\n – caret return and linefeed, representing the end of the packet

The packets control commands with their values that server accepts are listed bellow:

  1. PASSWORD (2) – the packet contains password data. It can be ignored if the server is configured with no password. But client still must supply this packet.
  2. CC_DESC (4) – the packet contains transmission description. Client is required to supply this packet even if end-user didn't specify one.
  3. BIN_HEADER (5) – the packet contains BIN header. Packets BIN_DATA and EPG_DATA are ignored until BIN_HEADER is supplied.
  4. BIN_DATA (6) – the packet contains BIN data that will processed to extract captions. This data is recognised according to presented earlier BIN_HEADER
  5. EPG_DATA (7) – the packet contains EPG data with following syntax
    1. c-string (bytes ending with \0) with start time in the “%Y%m%d%H%M%S %z” format
    2. c-string with stop time in the “%Y%m%d%H%M%S %z” format
    3. c-string with program title
    4. c-string with program description
    5. c-string with language
    6. c-string with category
  6. PING (55) – keep-alive packet with no data

If the server receives packet with unknown control commands it shall close connection.

Server communicates with client by sending 1 byte constants. These constants are:

  1. ERROR (51) – error happened on the server side so that it can not process client's data
  2. PASSWORD (2) – client supplied wrong password
  3. PING (55) – keep-alive constant

Client should ignore commands that are not defined by the protocol.

  1. After TCP connection is established, client must send these packets in specified order:
    1. PASSWORD
    2. CC_DESC
    3. BIN_HEADER
  2. Then, without waiting for server's responce client can send BIN_DATA, EPG_DATA and PING packets in arbitrary order.
  3. In case client presented wrong password server closes connection and sends PASSWORD byte.
  4. In case client didn't presented any required packets server closes connection and sends ERROR byte.
  5. If client notices that connection is closes it can read the data left in socket buffer to get the reason why it's closed.
  6. If an error occurs and server can no longer process clients' data, it shall send ERROR byte and close connection.
  7. Every 3 seconds client is required to send PING packets. If server doesn't receives them in 20 sec, it closes connection without sending anything.
  8. Every 3 seconds server is required to send PING packets. If client doesn't receives them in 20 sec, it may close connection and reconnect.
  • public/gsoc/repository_protocol.txt
  • Last modified: 2016/08/02 20:08
  • (external edit)