dvtp-server/docs/brief-protocol-reference

99 lines
3.8 KiB
Plaintext

# Brief distributed video transcoding protocol (DVTP) reference
All commands end with '\n' newline character; use of '\r\n' sequence is discouraged and likely would not be supported by servers.
Aliases:
< Sending data to the server
> Receiving data from the server
. Connection close
# Comments and descriptions
Example of a client communicating with the rendering server:
# -- Beginning of communication --
< HASH
> HASH {sha256_sum}
# sha256_sum - checksum of the target file (used to check if the file is cached locally already)
< SIZE
> SIZE {file_size}
# file_size - size of the original video file
< URL
> URL {video_URL}
# URL client can fetch the original video from
< SCRIPT
> SCRIPT {script_URL}
# URL client can fetch a compatible transcoding script (CTS) from
< NEXT
> CHUNK {sha256_sum} {seq_id} {start} {duration} {ping_interval} {worker_id}
# sha256_sum - checksum of the target file (used to check if the file is cached locally already)
# seq_id - id of the assigned chunk
# start - chunk begin timestamp in seconds
# duration - length of the chunk in seconds
# ping_interval - interval in seconds to wait before sending next PING message
# worker_id - ID of this system assigned by the server
# -- After all chunks are taken, but not fully rendered --
< NEXT
> WAIT {delay}
# delay - time in seconds client has to wait before sending another NEXT request
# -- After all chunks are fully rendered --
< NEXT
> FINISH
# this responce should be considered as a shutdown command and server will likely close the connection immediately, so should do the client
.
# -- Communication during rendering --
< PING {sha256_sum} {seq_id} {worker_id}
> PONG {status}
# status - 'waiting' if the chunk is still needed, 'done' if the chunk has already been processed by another worker (if the client receives 'done' status, it has to immediately drop the rendering and get a new chunk via NEXT request to not waste any time)
# -- After a successful render --
< UPLOAD {sha256_sum} {seq_id} {worker_id} {chunk_size}
# sha256_sum - checksum of the original file
# seq_id - ID of the chunk
# worker_id - ID of the client assigned by the server
# chunk_size - size in bytes of a file to be sent; incorrect values will result in chunk corruption, connection stalling and undefined behaviour
> ACCEPT
< {chunk_data}
# chunk_data - raw bytes directly read from the chunk file (NO END SEQUENCES TO BE APPENDED, ONLY ACTUAL FILE CONTENT!)
> ACCEPTED
# -- After a successful render with the same chunk uploaded by a different worker --
< UPLOAD {sha256_sum} {seq_id} {worker_id} {chunk_size}
# sha256_sum - checksum of the original file
# seq_id - ID of the chunk
# worker_id - ID of the client assigned by the server
# chunk_size - size in bytes of a transferred chunk; incorrect values will result in chunk corruption, connection stalling and undefined behaviour
> DISCARD
# Notice: server may accept the same chunk from different workers in case it chooses to
# -- If the uploading has been interrupted and did not finish correctly --
< REUPLOAD {sha256_sum} {seq_id} {worker_id} {chunk_size}
# sha256_sum - checksum of the original file
# seq_id - ID of the chunk
# worker_id - ID of the client assigned by the server
# chunk_size - size in bytes of a transferred chunk; incorrect values will result in chunk corruption, connection stalling and undefined behaviour
> RESUME {offset}
# offset - amount of bytes to be skipped at the beginning of the file
< {remaining_chunk_data}
# remaining_chunk_data - raw bytes of the chunk file starting from the offset the server specified
> ACCEPTED
# -- Client wants to drop the render job after being assigned to a chunk --
< ABORT {sha256_sum} {seq_id} {worker_id}
# sha256_sum - checksum of the original file
# seq_id - ID of the chunk
# worker_id - ID of the client assigned by the server
> ABORTED