CSU33031 protocol development and the information that is kept in a header to support the functionality of a protocol: Computer Networks Assignment, TCD, Ireland

1 Introduction

The focus of this assignment is to learn about protocol development and the information that is kept in a header to support the functionality of a protocol. Protocol design is always a balancing act between introducing functionality that relies on additional header information and the overhead that the additional header information introduces.

2 Protocol Details

The aim of the protocol is to provide a distribution mechanism for video, audio, and text content using a publish-subscribe mechanism based on UDP datagrams. The encoding of the header information of this protocol should be implemented in a binary format.

The protocol involves a number of actors: One or more subscribers, a broker, and one or more producers. A subscriber issues subscriptions for content to a broker and receives published content from this broker. The broker processes subscriptions and publications, keeps records of publications, and forwards content from publishers to potential subscribers. The header information that you included in your packets has to support the identification of subscriptions and published content – potentially consisting of a number of packets and the management of subscriptions and publications by the broker.

Figure 1: As a very simplistic starting point, a producer e.g. software of a video camera sends a frame to a broker. This broker distributes the frames to consumers who previously subscribed to content at the broker

As motivation, assume that you have been tasked to develop a new protocol for IRL1 streamers where content will be created by the streamer, sent to your broker, and distributed from there to an audience. LiveU 2 for example uses a proprietary protocol for a server that then can use the Secure Reliable Transport (SRT) protocol [6] to distribute video streams to streaming services. SRT[1]3 is a good example to look at for a simplistic header design.

The basic functionality that your protocol has to provide is to support subscriptions for content by consumers, publication of content by publishers, and distribution of content by the broker to interested consumers. Streams are made up of individual frames. The producer will send individual frames to the broker and the broker will forward the frames to the respective consumers. Frames may arrive out of order or not at all – a frame missing is not much of an issue for a stream; however, displaying an older frame after a newer one would result in a strange viewing experience. Your implementation needs to take this into account.

The assignment focuses on protocol design and communication i.e. you do not have to implement frontends that capture and display frames, print-outs to a screen or logfile are sufficient. The assignment information on Blackboard includes a number of frames for example, you could read

Your protocol should support multiple producers and multiple consumers at any given time i.e. there may be 3 producers, each with 2 consumers. Producers should be identified by a 3-byte code e.g. ”ABCD99” and their current streams are given a number, encoded in another byte e.g. “ABCD9901” for stream 1 by producer “ABCD99”. Consumers may elect to subscribe to a specific stream or to all streams from a given producer. This information has to be encoded in binary in the headers and be discussed as part of your header design.

With every protocol design, there are a variety of options that influence the amount of your header information- tion and functionality that can be added to a protocol. For example, a producer may send out frames as well as audio, or producers and consumers may send text related to a stream that is distributed to subscribers. The proprietary protocol used by LiveU allows for a streamer to send traffic over 4 different connections to a server and the server combines this information into a single stream to the consumer e.g. bytes 1, 5, and 9 of a frame are sent over connection 1, bytes 2, 6, and 10 are sent over connection 2, etc and if a part of a frame is dropped by one connection, the consumers would still receive the remaining parts. It is up to you to decide on the functionalities you intend to implement and how In the deliverables, you need to discuss the functionalities that you choose to implement and justify why you included them in your protocol.

The following flow diagrams, figure 2 are an example of visualizations of network traffic between components. They show the sequence of messages exchanged between components with the start of their transmission at the sender and their arrival at the receiver. Please use Flow Diagrams like these to document the communication between components of your implementation in your videos and in your final report.