This is a 3 minute presentation of Richard St. John at the february 2005 TED conference presenting the 8 keys to success he identified after interviewing 500 successful people.

This is a talk of Steve Jobs at Stanford  in 2005. It's really worth  viewing.

All along the development of DITP and DIS, the question of which business model to apply taps my mind. Here is a blog note I found really enlightening on this issue. 

"Better Than Free" by Kevin Kelly

In some discussion group we just settled, we were asked to write down what would be the most important for us in our lives. And to our big surprise 90% youngsters in the group used the words "recognition" or "social recognition". There wasn't any significant discussion before that could have biased this informal survey. It was surprising enough to catch my attention.

20 years later, here is how I explain this to myself. It is known for many years now that our brain has special centers responsible of fundamental drives in our behavior. These centers have been detected and localized by changes in people's behavior when altered by an accident or a disease. The drives are related to hunger, libido, aggressivity/love, etc.

Assuming that mankind is the product of an evolution driven by natural selection, the existence of such drive centers makes sense. It ensures perennity of our species from the biological and the physiological perspective. Maybe the social perspective did not get the same attention.

To me, the existence of a drive for social recognition would also make sense because it pushes toward social coherence and cohesion and thus also to stability while being flexible enough to preserve the capability of our society to evolve and adapt to context changes.

This social recognition drive is thus equivalent to sexual drive, with all the possible related pathology. Social recognition compulsion can for instance lead to mythomania or eccentric behavior.

So my impression, if you allow me to push the logic to its extrema, is that social network sites are a variant of porn sites. They just tickle the brain centers driving our behavior.

I would thus say that social networking is directly related to the social recognition drive, which is itself a kind of attractive magnetic force required to get social cohesion and coherence. If this is true, animals would show the same fundamental drive, and why not, ETs too.

Minimizing latency was one of the main aspects driving the design of the DITP protocol. You may check wikipedia for a definition of latency in the networking context.

While network speed has still allot of room to increase, network latency doesn't. Today 80GB/s backbone fiber links are getting common, and we know that there is no limit to reach Tera Byte/s speed or even above. We can easily achieve this by frequency multiplexing or adding more parallel fibers. So we have plenty of room to extend the number of Bytes/s we can send. We can expect a network speed gain of a factor of 100 or maybe even 1000 in the next 25 years.

On the other hand we have a hard and very close limit in transmission latency. This is all the fault of the speed of light limit (~300.000 Km/s). See the numbers. The distance between Paris (France) and New York (USA) is ~ 6000 Km. So it takes 20ms for a single bit to reach the other end and there is no way to lower this time unless we find some "worm hole" in our knowledge of physics.

We are still far from this lower bound limit, but only by a factor 10 or less. Thus a protocol designed for WAN (World Area Network) application should really care about latency.

Here is how I learned the lesson. I designed a protocol to transmit 2MB blocks between computers. The protocol was trivial and worked very well in LAN (Local Area Network) applications. We then had the opportunity to test it on a leased 6GB/s long distance connection between CERN (Geneva in Switzerland) and the university of Alberta (Canada). The surprise was that the bandwidth usage never exceeded 2%. We found out that it was caused by the network latency which was ~500ms. In this context, the  handshake time dominated the transmit time, something we didn't see in a LAN. So our protocol had to be redesigned ! Since that day I understood how important and critical network latency can be.

The first lesson we may learn from this analysis is that when designing a modern protocol for potential WAN usage, minimizing network latency is much more important than encoding concision.

The second important lesson is that inter-object communication will be impaired by the network latency of long distance connections. In such context I thus expect that the agent model will be more efficient. In this model, it is a piece code, a program or even a virtual robot that is sent to the remote host. And this is exactly what is already happening today with JavaScript code in web pages. I assume this tendency will develop and extend in the next 10 years. 

DITP is ready for this since it can be used as the transport layer of such agent transmission. All we need is a special remote service object acting as an agent host. This is on top of the DITP communication layer so that many different types of agents can coexist. The technology can thus also evolve and preserve backward compatibility. There are other reasons why DIPT has a good potential for such usage model, but it is still a bit early to expose them.

Network latency is an often disregarded parameter, but things might change in a near future when we'll get closer to the hard limit !

Progress on the design and the prototype implementation is going on. I now have a working prototype for the inter-object communication system. This helps me testing and refining the design. I also regularly review and update the specification documents.

On DITP, the current points of focus is to find a good way to manage the PDU (Protocol Data Units) processing like compression, authentication or enciphering. The user must be able to select and set them up in a snap while keeping it as versatile and flexible as possible.

On IDR, the current point of focus is a refinement of signed information encoding. A straightforward implementation is to simply append to signature to the signed information. But this annihilates all the benefits of the stream oriented encoding. Beside, invalid signature or data must be detected as early as possible. A solution has been identified, but fitting it nicely with the current encoding requires some more investigation.

A design process is a difficult task because we have zillion of decisions to make. The more complex the design, the more decisions there is to make, and likely we can make a mistake somewhere. The two heuristics I use to minimize this risk is first to keep the design as simple as possible and second to minimize the constrains on usage. The former is popular, the later much less.

DIS is based on the object model. DITP, the communication protocol used by DIS, is thus an inter-object communication protocol: it makes it possible to invoke methods of an object hosted in another process.

Client and service

The most simple API to do so, is to have a dummy object on the client side with exactly the same interface as the remote object. The methods of the dummy object, we'll call client, forward the call to the remote object we'll call service. Forwarding a method call means packing arguments into a message, send it to the service that process the call and sent back a message containing the result. From the user point of view there is no difference with calling a method of a local object.

In DITP the client object has an exclusive relationship with the remote service object it is connected to. The service is thus in fact an agent acting on behalf of the client. It is however still under control of the hosting process who can modulate its behavior according to client credentials or specific context. This design has also the benefit to associate a state to the service that may be transient or persistent (restored in a new connection).

Shared services are services that may be accessed by multiple clients simultaneously, Such services are implemented by a dedicated object supporting concurrent method invocations from the different services (agents).

Sequential and concurrent method invocation

Sequential method invocation is the most simple to implement and is also expected to be most frequent use case. The service process incoming method invocation requests one by one in the order of arrival, processing the next one only when the result of the previous one has been sent back. Adding a timeout control system will ensure that the system will never block.

Concurrent method invocation requires that each method invocation is processed by a dedicated thread. The service has to be thread safe and a congestion avoidance system is required in addition to the timeout control. It is thus more complex to design and implement.

DITP is designed so that simple communication models are simple to implement and use, and that more complex communication models can be implemented by composition.

Thus a client-service connection, called a channel, will only support sequential method invocation. Since DITP supports channel multiplexing and in both directions, supporting concurrent method invocation is implemented by encapsulating a pool of parallel client-service connections inside of the client and the service. Callbacks may then be implemented by multiplexing reverse client-service connections. .

When designing a data encoding, once the decision to use conventional binary representation is made, the next fundamental decision is whether the data should be memory aligned or not. RPC, CORBA and D-BUS use memory aligned data while ICE and IDR don't.

Memory aligned data ensures that 2, 4, 8, 10 or 16 byte values are stored at an address multiple of their size. For instance a 2 byte value (short integer) would then be stored at addresses 0, 2, 4 or 6. A 4 byte value (long integer) would be stored at addresses 0, 4 or 8 and an 8 byte value at addresses 0, 8, etc.

Some processors (Itanium, RISC) can only handle aligned data and the programmer has to add support for unaligned data himself. The x86 processor supports unaligned data but with a performance penalty. A quick benchmark on a X86 compatible processor showed that accessing unaligned data is nearly twice slower than accessing aligned data.

Memory aligned data requires padding space which on average can represent about 1/3 of used memory space. On modern PC with multi gigabyte RAM, this memory overhead is not relevant. But for hand held devices, embedded computer, long term stored or transmitted data, the memory overhead is much more relevant. A multipurpose encoding should thus care about memory usage as much as encoding/decoding performance.

It is to be noted that generating aligned data may in some case require additional computation and may thus have its own overhead. The code to marshal unaligned data is much simpler and straightforward. One use a simple pointer incremented by the accessed data type size. Getting rid of the alignment constrain also simplify PDU message encoding and encapsulation.

So basically the only drawback of using serialized and unaligned data encoding is the memory access overhead. But this penalty can be removed by ad'hoc hardware or processor instruction. For instance, processors could introduce a pointer variant behaving like an iterator on varying size data. This iterator could take advantage of asynchronous memory prefetching.

RPC, CORBA and D-BUS also benefit from a nearly direct mapping between encoded and internal data structure representation. This is fine when communicating with programs using this representation. But what about java, python or ruby which have their own data and object representation ? This optimization doesn't hold anymore.

This analysis has lead us to the decision to use sequential unaligned data for IDR encoding. What would be your choice on this matter ?

DIS is designed to address many shortcomings of existing internet services. But it is also subject to the network effect which means that its value is function of the number of users.

It's like a TV broadcasting system. Whatever the quality of the technology, without interesting broadcasts it won't attract users and without users it won't attract producers and without producers it won't get attractive broadcasts and then again no users. But when the feedback in such system becomes positive we get a virtuous circle which amplifies its spinning by itself. And once the virtuous circle is spinning one can tap its energy with advertisement, freemium or even a fee if the traction is strong enough.

To bootstrap it, one has to pick the right TV broadcast which has to be one that people want to see while also simple and cheap to produce. As you may guess this is a strategic choice.

Starting such type of system is not easy, but once rolling it is quite safe because it is difficult to stop and provides thus a protection against competitors. A good example is Google failing to catch on You Tube which ended up buying it.

Like the TV broadcasting system, DIS offers the liberty degree to pick the right bootstrapping application. It has to be something that people want while being also cheap and simple to produce.

The business model is also strategic. Offering a free service means not tapping energy from the virtuous circle which is good to get maximum acceleration. But at some point we need to tap energy from it so that we can invest it in development of new features and make it more attractive.

The business model and the bootstrapping application are thus key to success, but don't expect me to present them here before they are in production.

This picture of Marseille was taken from the top of Marseilleveyre, a small mountain south of Marseille. The small harbor in front is the harbor of Pointe Rouge. The Vieux Port, center of Marseille, and Notre Dame de la Garde, are not visible here.

One of the islands in the bay host the Château d'If that was a prison for sometime. This place was made famous by the roman "Le Comte de Monte Cristo" of Alexandre Dumas.