This page is a quick write-up on a data mixing project done as a class project. This page was written several months after the project to help anybody that stumbles upon it. If you need more information or clarification, I will be glad to discuss it with you.
This project was written in the latter half of a 10 week course on computer networks. The goal of the project is to demonstrate some of the techniques that may be used in real-time mixing of UDP data over the current IP network. It also sheds some light on areas that require advance consideration before a given data mixing service is implemented. Such areas include:
Though the work done for this project has no practical use in it's current form, it serves as a guide for future developers to services such as:
For this project, a finite number of clients in a mixing group will send their data to a mixing proxy. The data sent shall be a compressed M×N grid of ones (1) and zeros (0). The role of the proxy is to mix the data from all the clients and display the results.
There are two main components to this project, the client and the proxy. The client serves as a data transmitter and the proxy receives and mixes the data. For each group there may only one mixer and up to 35 clients. The limit on the number of clients is because of the mixing technique ( see below), it is not a network limitation.
The client for the real-time data encoding and mixing project generates a random cell grid of ones (1) and zeros (0) in a M×N grid (M and N need not be the same for each client).
The client is initialized with the dimensions of its grid, and the address and port of the proxy which handles its mixing group. 1,2 Then an initial request to join the group is issued to the proxy.
After the client joins the group, the first grid is then randomly generated and packed into an array of bits. The array is transmitted to the proxy using the UDP "connection" which was established at the beginning of the session. For verification purposes the curses library is used to display a copy of the grid on the screen. A side effect of this is that grid size is limited by screen dimensions.
An alarm is triggered every frame to cause a random "mutation" of old grid cells and the transmission of the newly mutated grid. The frame time is two seconds, a compile time constant which allowed me enough time to visually verify correctness.
To allow for a controlled simulation of network conditions (and a natural exit), the proxy will scan the client keyboard and respond to the following commands:
| Q | Quit |
| D | Drop a packet. Skip a sequence number, and don't transmit this frame. |
| S | Skip a packet. Skip a sequence number, and transmit this frame. |
| R | Reverse sequence numbers. Transmit next frame's number, this frame and this frame's number, the next frame. |
The proxy for the real-time data encoding and mixing project. It mixes grids of random cells of ones (1) and zeros (0) transmitted by its clients.
When a client joins the group, a storage array for that client's latest data is added to a collection of client data.
An alarm is triggered every frame which causes the proxy to mix data according to its mixing algorithm. The frame time is two seconds, a compile time constant which allowed me enough time to visually verify correctness.
When the proxy receives a client's packet, it compares the sequence number of the new packet with the sequence number of the last packet accepted from the client. If the sequence number is greater than the last accepted sequence number, the proxy will do the following:
The data is stored as a floating point value so that lost packets may be handled in a semi-graceful manner. (see below)
Once every two seconds a frame is mixed. All updated data is added together and any data not updated this frame is approximated (see below). Any non-integer cells are rounded to the nearest integer value. Finally the results of the mixed grids are displayed on the proxy's terminal. I know that the mixing is not so difficult, but any algorithm could be use here. It wasn't the point of the program.
During the mixing, if any client's data is not marked current for this frame, it is considered to have a lost packet. The current algorithm for handling the lost packets is to halve the value of the each cell in the previously received packet and treat the halved values as current.
| Makefile | Makefile for this project |
| client.c | Mixer client |
| proxy.c | Mixer proxy |
| utils.c |
Utility routines and used by both the client and the proxy. |
| utils.h | Data type, constants, and prototypes to utility routines and used by both the client and the proxy. |
Given time, the following items might be worth adding to this project:
1. In order for a session to be established, the proxy
must be initialized prior to the client.
2. Only one client per proxy may exist at any IP
address at a time.
Home
Last updated on November 2, 2000