Screen Casting in Mac OS X Snow Leopard

Posted on by

I recently wanted to practice a presentation I am giving my class on kernel design in modular operating systems; however, every time I went to practice it I felt really silly talking to my computer without a headset on.  So, I thought I’d see if there is a quick and easy way to record myself as I practice.  It turns out in Mac OS X Snow Leopard (10.6) there is!  The key is to creating the screen cast in QuickTime Player (bundled with Snow Leopard).  To make the screen cast follow the steps below.

  1. Open QuickTime Player

    rSpotlight

  2. Go to File -> New Screen Recording

    New Screen Recording

  3. Select your audio input from the drop down menu on the right
  4. Hit the “Record” button
  5. Work your magic! (Do whatever you wanted to record)
  6. Hit “Stop Recording” in the Menu Bar

    Stop Recording

I’ve been using it for a little while now and it seems to work quite well, but of course if you want a full fledged screencasting system then check out an app like ScreenFlow.

Weekly Free Writing

Posted on by

For the last week I’ve been at home sick and only yesterday started getting back into the normal routine.  While laying there one day I had this idea to try and do one “free write” post per week.  The idea is that each week I’ll pick a topic and then just write about it for a bit and see what happens.  From this I hope to get a variety of things depending on the topic selected and how related it is to my current work.  In the case of something on topic and related I hope to get a chance to try and clarify my thoughts.  In the case of topics that aren’t closely related, I hope to get a chance to explore new areas.  But, in all cases I hope to get a chance to see what new ideas come from just letting loose and seeing what happens.

iOS Apps for Project Moped

Posted on by

I’ve spent some time over the last week working on the iOS apps for Project Moped.  The plan is to create a “universal” app that can run on an iPhone and an iPad.

At this point in time only the iPad version of the app is functional — I’ll be working on the iPhone version later today — and it is able to play video from the local device.  In order to stream video to the device I will first create a temporary file on the device.  libmoped will then append content as it is received to the end of this file while the player reads it.  I plan on completing the basic functionality for the iOS apps over the next few days at which point I will once again turn my attention to the library implementation.

UPDATE: I have just posted the code for the iOS apps to my github repository at https://github.com/lightbulbone/Moped

Microkernels: Depending On Application Level Components

Posted on by

Ever since I was introduced to the idea of microkernels, such as Mach and L4, I’ve found them to be extremely fascinating.  They take something extremely complex (an operating system kernel) and break it into smaller parts that are manageable, easy to work with, and flexible.  A primary goal of a microkernel is to move as much functionality into user space as possible.  The reason for this is that this produces a kernel which is smaller, more reliable, and easier to maintain.  Well, recently I read “Are Virtual Machine Monitors Microkernels Done Right?” by Hand et al. which raised one disadvantage to microkernels that I had never really thought of.

The issue I’m referring to is what they call liability inversion — a potential result of the minimalistic nature of the microkernel.  The issue is that due to the goal of pushing as much functionality outside the kernel as possible the kernel can then become dependent on services at the application level.  Consider, for example, a process scheduler.  A monolithic kernel would contain functionality to both execute a process and select which process should be executed next.  Conversely, a microkernel may only contain the functionality required to execute a process and the selection of which process is to be executed is delegated to an application level service.  By moving this decision this critical decision into an application level service the kernel has effectively transferred liability to the application level service.

The primary ramification of liability inversion is that the kernel has now given up control of a critical system service and may be forced to wait potentially causing overall system instability and decreased performance.  According to the paper a variety of solutions have been proposed to avoid deadlock; however, the paper deems these solutions inelegant.  Since there is little else said about this issue in the paper and to me this is a larger issue than something like decreased performance due to the time required for upcalls to occur I plan to try and dig a little deeper into this area.  In doing this I hope to gain some more insight into why microkernels have been largely unsuccessful in industry settings as well as issues to be aware of during my exploration of extensible operating systems.

 

Hand et al. Are Virtual Machine Monitors Microkernels Done Right?. Proceedings of the 10th conference on Hot Topics in Operating Systems-Volume 10 (2005) pp. 1

Project Moped: An Update

Posted on by

Over the better part of the last month a considerable amount of work has been completed on Project Moped.  The most significant undertaking of which is beginning to write the code needed for Project Moped.  However, before any code was written a couple steps were taken.

Once the idea for Project Moped had been solidified in early February an investigation of current mobile devices and operating systems commenced.  The platforms considered included: Apple iOS, Google Android, RIM BlackBerry OS, Nokia Meego, and Symbian OS.  Of these it was decided to proceed with Apple iOS due to my familiarity with the platform, previous development experience, and available hardware for testing.  Furthermore, selecting iOS allowed for further exploration of a platform that promotes rich media usage.

Following the selection of a platform for development and testing was an investigation of current technologies used to create peer-to-peer networks.  The two primary concepts explored were distributed hash tables (DHTs) and the BitTorrent protocol.  DHTs were investigated because the routing and object location services they offer applications built on top of them are extremely powerful and allow for a wide range of applications.  I looked into several DHTs including: Chord, CAN, Pastry, Kademlia, and Dynamo.  While the services a DHT offers are powerful it was unclear to me how I could leverage them in order to provide the file sharing encapsulated in Project Moped.  For this reason I also looked into the BitTorrent protocol in order to find ways in which I could leverage existing systems to expedite development.  Although the concept of file sharing present in BitTorrent is more in line with the vision for Project Moped compared to a DHT based solution, BitTorrent’s reliance on metainfo files, trackers, and lack of geographic location awareness prompted the need for solution catered to mobile nature of Project Moped.

Due to the similarity between Project Moped and BitTorrent, and the lack of time currently available, it did not make sense to design a new protocol from scratch.  Instead of doing this it was decided to use the BitTorrent protocol as a base and modify it as needed to provide the functionality required by Project Moped.  This protocol design is still ongoing and is occurring concurrently with software development.

As previously noted, the process of writing code for Project Moped has begun.  The code consists of two parts: a library implementing the underlying peer-to-peer functionality, and an iOS application to test the network and provide insight into the behavior of the network.  The library (libmoped) is being implemented in C and tries to achieve portability whenever possible.  Progress on libmoped has come along smoothly and I am currently working on implementing a system to manage routing tables.  Code for libmoped can be found at https://github.com/lightbulbone/libmoped.  The iOS test application has seen less attention lately; however, there has been some consideration as to whether the application should be designed to share audio or video files.  There has also been some preliminary work in laying out the test application with minimal code written.\

The next steps to be taken are to: continue implementation of libmoped, solidify the plan for the iOS test application, and determine a set of metrics that can be used to evaluate network performance and user experience.  Lastly it will be necessary to setup a test environment and evaluate the system with and without a peer-to-peer overlay.

Peer Discovery: MANETs, Multicast, and CDN Edge Nodes

Posted on by

I spent some time earlier today considering what options are available for peer discovery in Project Moped.  In doing so I came up with three alternatives: MANETS, multicast, and CDN edge nodes.

Mobile Ad hoc NETworks (MANETs), while not strictly a method of peer discovery, provide a basis for creating loosely bound mobile networks.  They are typically used in situations where either a communication infrastructure is not available.  For example, MANETs have a potential application in developing countries where the internet infrastructure we use every day does not exist.  The appealing factor of MANETs is the inherent ability to support highly dynamic mobile networks in an efficient manner.  Furthermore, there has been a significant amount of research in developing a P2P overlay network on top of a MANET.  While this is a fascinating area of research and Project Moped could definitely benefit from it I am hesitant to pursue the idea any further due to the large overhead associated with developing software for the MANET.  That being said an investigation of a P2P network built on top of a MANET would serve as an excellent recommendation for future work.

I also looked into using IP multicasting in order to coordinate peers in a distributed manner.  The idea behind IP multicasting is that a source node will send a single message addressed to a group and then receivers can use the Internet Group Management Protocol (IGMP) to join the group.  Once a receiver has joined it will then have any messages addressed to the group delivered to it.  My idea for incorporating this technique into Project Moped was that, upon boot, each peer would join the Project Moped group and then it can advertise its presence to allow peers currently on the network.  Similar to the use of MANETs, this sounds like a great idea however my knowledge of IP multicasting is quite limited and I am unsure if this kind of usage is possible.  Again, due to the limited amount of time available for Project Moped I am going to leave IP multicasting as a potential improvement to be investigated during future work.

The last option is to leverage the fact that in a CDN network all clients eventually communicate with an edge node.  Since the edge node will be assisting in the bootstrap process it seems logical that, as a proof-of-concept implementation, we let the edge node maintain a list of peers that can be queried and replicated across other peers.  The idea behind this is fairly straightforward.  After being directed to an edge node, a client will be a member of the P2P network.  At this point the edge node can add that peers presence to a database of available peers.  At this point the peer can request a copy of the database for its own use.  After this replication has occurred there must be a system in place to allow for management of peers as they enter and leave the network.  The addition of a peer could be handled by the edge node sending a message to known peers indicating the arrival of the new peer.  Removal of a peer could be handled by the leaving peer sending out a departure message to all neighbours.  The other situation to be considered is when a peer transfers from one edge node to another.  In this case the peer could send a departure message to its old set of neighbours, request a new list from the new edge node, and then advertise its presence to the new set of peers.  Note that while it is possible to cache a list of previous neighbours for a peer it is likely not practical due to the highly dynamic nature of the mobile network.  For this reason I don’t believe there would be much, if anything, to be gained by performing any caching of neighbours.

Project Moped: Laying The Groundwork

Posted on by

At the end of my last update I mentioned that I was planning to spend some time this week looking at how I would simulate a CDN in the lab and begin to layout the groundwork for the iOS application.  Well, it turns out I was slightly optimistic in my estimation and that I’ve only had a chance to do a bit of preliminary work on the iOS component.  Note that I have had a quick look at some methods for simulating a CDN such as using hostap, Squid, and Coral.

Earlier in the week I spent some time looking at how to best modularize the projects code base.  I decided to break it into two parts: a library (libmoped) that provides all the services necessary for Project Moped, and an iOS application that uses the library.  Having never written a library for iOS, or at all for that matter, I thought the best place to start would be knowing how to build my code.  My original plan was to develop this library and make it available as an iOS Framework, but it turns out Apple doesn’t allow developers to create custom frameworks for iOS.  For the curious folks out there the reason for this is that a framework, at it’s core, is a dynamic library and since all non-Apple software runs in a sandbox no code can be shared between applications which makes a framework somewhat useless.  Never fear though!  While Apple does not allow custom dynamic libraries, they have nothing against developers using custom static libraries.  Note that while Apple does not allow dynamic libraries in iOS, I see no reason why this library can’t be platform independent and therefore compiled as either a static library or a dynamic library.

The next step is to identify what exactly the library must provide.  I’ve come up with a list of five components that I feel are essential.  The components are:

  • Bootstrap
  • Peer discovery
  • Content discovery
  • Location services
  • Session transfer

At this point I have only considered bootstrapping, peer discovery, and content discovery so I will only be discussing those, the remainder (location services and session transfer) will be covered in a future project update.  The process of bootstrapping is central to a peer-to-peer network because it is the process that allows a peer to join the network.  In a typical peer-to-peer network a new peer will notify a predefined server of its arrival and then notify any cached peers.  Since Project Moped is being designed to extend current CDNs we are fortunate in that we can leverage an existing CDN edge node as a bootstrap server.  When a new peer comes online it will first go through the CDN process of figuring out which edge node is closest to it.  Once the peer has been directed to the appropriate edge node it has joined the network and can then proceed to finding peers.

Peer discovery in libmoped can be accomplished by leveraging the fact that the edge node maintains a list of all connected peers.  This list can act as an index in which new peers can advertise their presence.  The primary issue with this idea is that when a mobile client is equidistant between two edge nodes it may benefit from contacting peers in both groups.  In an effort to mitigate this problem I will be looking at other ways in which peer discovery can be done.

Content discovery will also play a significant role in the success of this project.  Although untested, I believe that content discovery can be accomplished by first allowing a new peer to access the desired content through the standard CDN interface.  Once this connection has been established the peer will receive a key that uniquely identifies the content and that can be used for lookups among peers.  At this point a distributed hash table can be used to provide a key-value data store.

Over the course of the next week I’d like to start writing the code for libmoped; however, I first need to clarify the semantics of the various components.  I will be focusing the next few days on location services and session transfer as well as fleshing out the details over the other components.  Another high priority will be to investigate software and methods available for simulating a CDN in the lab.