Private:almohammadi - Revision history

Balmoham at 23:24, 10 August 2010

2010-08-10T23:24:28Z

Balmoham at 21:30, 3 August 2010

2010-08-03T21:30:40Z

Balmoham at 19:50, 20 July 2010

2010-07-20T19:50:03Z

Balmoham at 22:27, 13 July 2010

2010-07-13T22:27:17Z

Balmoham at 19:49, 13 July 2010

2010-07-13T19:49:50Z

Balmoham at 22:49, 6 July 2010

2010-07-06T22:49:06Z

Balmoham at 22:46, 6 July 2010

2010-07-06T22:46:45Z

Balmoham at 22:44, 6 July 2010

2010-07-06T22:44:36Z

Balmoham at 17:15, 6 July 2010

2010-07-06T17:15:57Z

Balmoham at 23:00, 29 June 2010

2010-06-29T23:00:40Z

@@ Line 1: / Line 1: @@
 Summary of accomplishments by Bassam Almohammadi.
 == August 2, 2010 ==
 * implemented a unicast connection that connects with the streaming server for every streaming program.

@@ Line 1: / Line 1: @@
 Summary of accomplishments by Bassam Almohammadi.
 == July 19, 2010 ==
 * implemented all the test cases and added them to the src/test folder in the repository.

← Older revision		Revision as of 19:50, 20 July 2010
Line 1:		Line 1:
	Summary of accomplishments by Bassam Almohammadi.		Summary of accomplishments by Bassam Almohammadi.
		+	== July 19, 2010 ==
		+	* implemented all the test cases and added them to the src/test folder in the repository.
		+	* documented all the test cases in the test section of the design document.
		+	* performed a thorough testing for all the APIs in my module and made all the necessary fixes. The module has passed all the tests.
		+	* the stream reader is now fully functional according to the design. Need to be integrated with the scheduler if we want to test bursts generation.

	== July 12, 2010 ==		== July 12, 2010 ==

@@ Line 15: / Line 15: @@
 * I assume all the packets that should be handled by the Stream Reader contain RTP payload. Thus I relay on the timestamp in the RTP header to sort packets. If we shall handle any other type of packets then I think we should filter them differently from RTP packets? consequently, I shall add a local mechanism to record the timestamp for these packets.
 * according to the design, the implementation should work fine with multicast. However, I'm not sure how the scenario will be different with handling unicast streams? do we need to support this?
 TODO:

← Older revision		Revision as of 19:49, 13 July 2010
Line 1:		Line 1:
	Summary of accomplishments by Bassam Almohammadi.		Summary of accomplishments by Bassam Almohammadi.
		+
		+	== July 12, 2010 ==
		+	* Updated the design document for the stream reader, and included new APIs required for the scheduler.
		+	* Completed the integration of the stream reader based on the new design:
		+	** in MTV: added a new thread for the Sniffer.
		+	** in Configuration Manager: added a new case for "Stream" Programs.
		+	** in Programs: added a new constructor to handle the creation of the UDPReader for the stream.
		+	** completed the Sniffer implementation.
		+	** completed the UDPReader implementation of the new APIs.
		+	** added new fields to the Ip_pkt class to use it for buffering packets in the UDPReader.
		+	** Used mutex to control the shared buffers between the Sniffer thread and the Timeslicer thread.
		+	ISSUES:
		+	* still not clear about handling audio/video stream. My current implementation considers them equal and sort them in a single buffer based on their timestamp. I assume the rest is for the scheduler to handle.
		+	* I assume all the packets that should be handled by the Stream Reader contain RTP payload. Thus I relay on the timestamp in the RTP header to sort packets. If we shall handle any other type of packets then I think we should filter them differently from RTP packets? consequently, I shall add a local mechanism to record the timestamp for these packets.
		+	* according to the design, the implementation should work fine with multicast. However, I'm not sure how the scenario will be different with handling unicast streams? do we need to support this?
		+
		+	TODO:
		+	* integration testing [and debugging].
		+	* update test cases documentation.

	== July 5, 2010 ==		== July 5, 2010 ==

@@ Line 8: / Line 8: @@
 ** the challenge here is in returning the ready Burst instance. Currently the timeslicer::schedule() makes only one push_request per program for one Burst instance. I propose declaring the program type in the public field of 'Program' class. At the timeslicer::schedule(), if we want to schedule a burst for a program we shall schedule two bursts for live programs!
 * Generally almost done with the integration. The only thing left is to load packets from the UDP buffer to the burst. I'm trying to figure out the function of get_candidate(current, deltaT) to write a parallel one for the UDPReader.
 == June 28, 2010 ==

@@ Line 6: / Line 6: @@
 * created a new constructor in the Program class for live programs. Live programs, and the program type in general, shall be identified by a new 'string' field in the configuration file.
 * created two instances of UDPReader for every live program, one for audio and one for video. Both instances share the same IP but different ports.
-** the challenge here is in returning the ready Burst instance. Currently in the timeslicer::schedule() make only one push_request per program for one Burst. I propose declaring the program type in the public field of 'Program'. At the timeslicer::schedule(), if we want to schedule a burst for a program we shall shall schedule two bursts for live programs!
+** the challenge here is in returning the ready Burst instance. Currently the timeslicer::schedule() makes only one push_request per program for one Burst instance. I propose declaring the program type in the public field of 'Program' class. At the timeslicer::schedule(), if we want to schedule a burst for a program we shall schedule two bursts for live programs!
 * Generally almost done with the integration. The only thing left is to load packets from the UDP buffer to the burst. I'm trying to figure out the function of get_candidate(current, deltaT) to write a parallel one for the UDPReader.

← Older revision		Revision as of 17:15, 6 July 2010
Line 1:		Line 1:
	Summary of accomplishments by Bassam Almohammadi.		Summary of accomplishments by Bassam Almohammadi.
		+
		+	== July 5, 2010 ==
		+	* Added Sniffer class to the design and the code. Its function is to listen for incoming live stream on a separate thread and filter packets into UDPReaders packet buffers.
		+	* created a thread for the sniffer at the initialization of the Mtv class.
		+	* created a new constructor in the Program class for live programs. Live programs, and the program type in general, shall be identified by a new 'string' field in the configuration file.
		+	* created two instances of UDPReader for every live program, one for audio and one for video. Both instances share the same IP but different ports.
		+	* Generally done with the integration. The only thing left is to load packets from the UDP buffer to the burst. I'm trying to figure out the function of get_candidate(current, deltaT) to write a parallel one for the UDPReader.

	== June 28, 2010 ==		== June 28, 2010 ==