October 19, 2010

A Fun Poster

This poster was laying around my office.  Since it did not seem to be visible on the web I thought, why not?

Posted by karl at 8:29 PM | TrackBack

October 1, 2010

In a world of net non-neutrality we will need something better than the sockets API

I saw a thing on Slashdot this morning entitled Microsoft Sues Motorola Over Android-Related Patent Infringement

What caught my eye is a Microsoft claim that it has a patent on "notifying applications of changes in signal strength and battery power".

That reminded me of a long-standing complaint I have about the sockets interface used under nearly every networking application on Linux, Bsd, Windows, and MAC OS.

The complaint is that in the sockets API there is very little advisory push-back that can tell applications to alter their behavior.  (The sockets API exercises non-advisory control by blocking transmission for a while.)

This means that most network applications are not well suited to interact constructively with any of the net non-neutrality mechanisms that are arising.

At the most course layer we need to formalize the notion of a "bandwidth broker".

The "bandwidth broker" idea arose in the mid 1990's.  The basic idea was that applications would converse with the broker to negotiate both the time and mode of net use.  A bulk-backup application, might negotiate for a time in which it could move some given number of gigabytes of traffic to a specified archive.  An interactive video application might arrange for admission to a traffic engineered MPLS path.  That application might adapt its use of codecs to meet link quality options presented by the bandwidth broker.

(Just before it collapsed, the ill-favored Enron Corporation was exploring commercial arbitrage of bandwidth.  But that, I believe, was more of an automated exchange of circuit horsepower than the kind of application agile mechanism that I am describing.)

At a lower level we need to extend the sockets interface so that applications can be given useful advice about how the network is performing at any given instant.  This might be hard to do given that many network applications are built around a simple blocking read-react-write loop rather than the more adaptable select()/poll() (or better, yet a "reactor" abstraction such as found in the ADAPTIVE Communication Environment (ACE)).

Posted by karl at 1:35 PM | TrackBack