PiBox

• php socket client tutorial: http://www.binarytides.com/php-socket-programming-tutorial/
• javascript example to handle unload event: http://stackoverflow.com/questions/653976/call-url-before-closing-of-browser-window

The daemon should:

1. Accept inbound XML messages
2. Validate them
3. Generate a UUID
4. Return the UUID or NACK

The accepted XML is parsed and a data structure placed on a queue that is handled by a separate thread to manage child processes.

XML format is TBD. Using XML allows me to use a template file within the web server where tags can be replaced by PHP to specify what ffmpeg should be opening and how. libxml2 is already available in PiBox's rootfs.

I need a way to start an autoconf project. Some possible tutorials:

• http://www.dwheeler.com/autotools/ - this seems to be the best, most recent and its a video tutorial.
• http://smalltalk.gnu.org/blog/bonzinip/all-you-should-really-know-about-autoconf-and-automake
• http://mij.oltrelinux.com/devel/autoconf-automake/
• http://markuskimius.wikidot.com/programming:tut:autotools/
• http://www.lrde.epita.fr/~adl/autotools.html
  • http://stackoverflow.com/questions/1746135/getting-started-with-autotools

I've created a new project, piboxd, under the pibox umbrella on gitorious. An autoconf-based build has been created and I've started work on the core of the daemon. So far I've got command line parsing, logging, embedded build date/version, daemon mode and initial support for queueing of inbound messages. The server thread that accepts inbound messages also has simple nc-based unit tests.

I've got a preliminary design for the daemon including the simplistic protocol for messages to it. Messages are one-way, which means a request comes in and is processed by the daemon but is not acknowledged. This design has a block diagram in a Dia project which will be included in the source tree for piboxd.

After thinking about the original description of the daemon I've started to feel there might need to be one additional message from the browser (via javascript, probably through a PHP proxy request) that lets the daemon know the page is being viewed. If the daemon doesn't get this within a few seconds (it's very close to the browser, physically, in the trailer) then it should kill the process it just started. The javascript on the web page could repeat this heartbeat message periodically. This is a safeguard against abandoned streams. Additionally, the stream could have a time limit placed on it so it times out after a while. A timeout on the web cam would be useful. A timeout on streamed movies might not be.

Update on development of the daemon:

There is a small protocol for messaging between the web interface and the daemon. That protocol is structurally supported but not all features are implemented yet. Most importantly, support for starting and stopping a webcam stream is implemented. Unit tests are written for this functionality as well, though they don't verify that crtmpserver connects to the stream. They only test that launching ffmpeg using the correct command line is attempted.

What's next:

1. Add test for multiple webcam stream requests. Only one request for the webcam can be active at at time. This is implemented in the daemon, but not tested yet.
2. Add negative tests for queue processor. That would be tests that send badly formatted stream requests.
3. Add duration test for queue processor. That would be a test that starts and stops tests over an extended period of time to test long term stability.
4. Implement heartbeat processing. This should update the specified tag's heartbeat field with a new timestamp. That timestamp is local - when the message was received by the daemon.
5. Implement thread that handles automatic shutdown of a stream if no heartbeat is received within a configurable timeout period. Be sure to call shutdown for thread from main().
6. Write init script for daemon.
7. Add packaging (opkg) for daemon.
8. Verify cross compile works.

After that, I cam return to the web interface to write the PHP code that calls the daemon and then the Javascript that provides the heartbeat call and the termination call to the PHP.

• Implemented heartbeat processing.
• Added thread to expire abandonded streams.
• Updated unit tests to support both.

What's left:

• Write init script for daemon.
• Add packaging (opkg) for daemon.
• Verify cross compile works.
• Run the daemon with Valgrind and the timed duration test to see if it leaks

• Completed init script.
• Added packaging (opkg) targets.

What's left:

• Verify cross compile works.
• Run the daemon with Valgrind and the timed duration test to see if it leaks

• Added cross compile script.

What's left:

• Run the daemon with Valgrind and the timed duration test to see if it leaks

I've cleaned up all valgrind reported leaks. One interesting one is that valgrind reports a dlopen "still reachable" leak if I use pthread_exit() when my threads exit. To avoid this I now call return(0) instead since the thread itself will be cleaned up immediately afterward. That's because where this happens is when the daemon is exiting anyway.

So now valgrid runs cleanly running simple tests. I'm going to run the timed test and make sure there are no long term leaks. Once those (if any) are cleaned up I'm done with this version of the daemon.

Updated unit tests to make it easier to run individual subtests. Fixed leaks exposed in various subtests as reported by valgrind. Timed tests of 300 seconds now reports no leaks.

The daemon is completed, though its not tested on the hardware to verify it correctly starts the webcam stream. However, any bugs uncovered in that testing will be opened as new bugs.

This issue can be closed.