Benoit Perroud : concepts and cloud ready applications

Cassandra, hector, maven and tomcat

2011-08-05T22:48:00.005+02:00

Cassandra (v0.7 and 0.8), hector (version compatible with Cassandra), maven and tomcat bound together result in a warning at tomcat startup :

INFO: validateJarFile(/...<webappspath>.../WEB-INF/lib/servlet-api-2.5-20081211.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class

Nothing harmful here, but as we want to do things as clean as possible we should avoid violating Servlet Spec 2.3.

So running a dependency:tree help to find out the guilty dependency :

[INFO] +- me.prettyprint:hector-core:jar:0.8.0-2:compile
[INFO] | +- org.apache.cassandra:cassandra-all:jar:0.8.1:compile
[INFO] | | +- org.apache.cassandra.deps:avro:jar:1.4.0-cassandra-1:compile
[INFO] | | | \- org.mortbay.jetty:jetty:jar:6.1.22:compile
[INFO] | | | \- org.mortbay.jetty:servlet-api:jar:2.5-20081211:compile

Hum hum, org.mortbay.jetty:servlet-api:jar:2.5-20081211. We found the responsible of the problem.

Using <dependencymanagement> in our pom.xml file we will be able to mark this dependency as provided and the problem should flight away :

<dependencymanagement>
    <dependencies>
      <dependency>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5-20081211</version>
        <scope>provided</scope>
      </dependency>
    </dependencies>
</dependencymanagement>

Build, deploy, and that's it !

NoSQL Overview @Webmardi

2011-03-07T14:32:00.001+01:00

Tuesday 1st of March 2011 I gave an overview of NoSQL at the Webmardi monthly event. The presentation was hosted by Webdoc. Thanks all for the warm welcome !

Some pictures :

The slides are available on Slideshare : NoSQL Overview, implementation free.

It is called "Implementation free" because I didn't want to focus on a particular implementation of a NoSQL datasore, but rather generalize concepts of "What is NoSQL". And it's a tricky answer to formulate :)

So what is NoSQL ? It's a family of datastores that does not have SQL as main data access pattern.

The presentation was hosted by Webdoc : http://www.webdoc.com.

Eventually Consistency demystified

2011-01-06T12:40:00.006+01:00

In my crusade into the NoSQL world, Eventually Consistency is everywhere. I want to demystify this property a little bit here.

But let's begin with an example to have the same base for the discussion :

Let "Node1", "Node2" and "Node3" be three nodes (servers) that are part of our distributed datastore.
Let "User A", "User B", "User c" be three users wanting to read and write data in our fictive distributed datastore.

At time (1), "User A" write the value "A" to "Node1". "Node1" will replicate asynchronously this value to both "Node2" and "Node3" (specific to my example).
At time (2) the write call of "Node A" returns. But the replication of value "A" hasn't been completely propagate to "Node2" and "Node3".
At time (3), "User B" and "User C" will read value "A" from "Node1" and "Node2" respectively. "User B" got the latest value (because it reads the node which initiate the update), "User C" will read either the old or the new version of "A", but without any guarantee regarding what it will read.

In a future time (5), "User B" and "User C" re-read value "A" and then got the same value. At this point of time, the datastore is consistent.

Immediate Consistency

In a Immediate Consistency, opposing Eventually Consistency, the write call from "User A" should wait till the replication is done on other nodes before returning, and replica nodes ("Node2" and "Node3") should be synchronized to expose the new value at the same time.

Moreover, if "Node1" is unable to talk to "Node2", the write replication will probably fail then the write call from "User A" will fail.

As we can notice, Immediate Consistency is hard to scale (see two-phase commit or paxos algorithm), because it increases the latency of the writes and makes the system not redundant to failure.

Trade-off for scaling writes

Eventually Consistency is then a trade-off for scaling writes that seems reasonable in certain use-cases.

DNSSEC NSEC3 domain hash computation algorithm

2010-12-23T10:38:00.004+01:00

DNSSEC is a DNS extension in order to authenticate and ensure integrity of DNS responses, in order to offers protection against DNS spoofing.

DNSSEC comes with two "denial of existence" mechanism : NSEC (RFCs 4033, 4034, 4035) and NSEC3 (RFC 5155).

Now how "denial of existence" works ?

When a query is performed on a non-existing domain, a specific answer is returned to the resolution client, given the closest domains that are alphabetically before and after the queried domain. But what is very sensible in this way of proving the non-existence of a domain is that we can easily enumerate the whole zone.

That's why NSEC3 was designed to prove the non-existence of a domain, but in the same time to avoid the zone walk through.
Instead of simply returning the closest domains, it returns a hash of the domains.

How to compute NSEC3 Hash ?

I will detail a little bit how this NSESC3 hash is computed :

I you have a look at a zone, you will find additional records, like NSEC3PARAM :

example.com. NSEC3PARAM 1 0 12 aabbccdd

The format of such record is composed of :

an algorithm field. 1 means SHA1
a flags field
an iterations field
a salt, represented as a sequence of case-insensitive hexadecimal digits.

Then the hashing algorithm is given by :

 IH(salt, x, 0) = H(x || salt), and
IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0

With my example.com domain, the hash algorithm will be :

IH(fromHexStringToByte("aabbccdd"), toCanonicalWireFormat("example.com"), 12)

fromHexStringToByte is a base 16 decoder : fromHexStringToByte("aabbccdd") = [0xaa, 0xbb, 0xcc, 0xdd]. See RFC4648

toCanonicalWireFormat convert the domain in wire format using its canonical form : toCanonicalWireFormat("example.com") = [0x07, 0x65, 0x78, 0x61, 0x6d, 0x70, 0x6c, 0x65, 0x03, 0x63, 0x6f, 0x6d, 0x00]. See RFC4034 (canonical form), RFC3845 (wire format)

And that's it, you are now able to compute the NSEC3 hash of your favourite domain. You just need to wait for NSEC3PARAM to be published in the respective zone to got all the necessary parameters :)

Using java.net.InetAddress.getByName() to validate an IP Address may be too permissive

2010-11-19T14:19:00.004+01:00

java.net.InetAddress.getByName() static function can be used for validating a given IP Address.

But doing that way you need to pay attention to certain side effects border values :

String ip = "1.2.3.4"; // valid IP Address
InetAddress address = InetAddress.getByName( ip );
Assert.assertEquals( ip, address.getHostAddress() ); // Pass. OK

String ip = "1.2.3"; // invalid IP Address
InetAddress address = InetAddress.getByName( ip );
Assert.assertEquals( ip, address.getHostAddress() ); // Pass. KO !

If you have a look a little deeper, you will see that 1.2.3 is transformed in 1.2.0.3, which after transformation become a valid IP Address.

Having that in mind, a IP Address validation function can look like :

public static boolean validateIpAddress( String anIpAddress ) {
 try {
  InetAddress address = InetAddress.getByName( anIpAddress );
  return address.getHostAddress().equals( anIpAddress );
 } catch (final UnknownHostException e) {
  return false;
 }
}

Moving from ELCA to Verisign

2010-10-09T13:46:00.003+02:00

I had a great time at ELCA Informatique SA, working for almost 3 years on Secutix, a complete ticketing system. But now it's time for me to move forward and see something else : different projects, different colleagues, different cultures, speak more English, nearer from home, and so on...

That's why I will move to Verisign, beginning the 2nd of November (the 1st is day off :)). Working on the heart of Internet (aka DNS) is some kind of child's dream which I will be able to realize ! I'm really excited to see how root name servers work, what's behind Registrars (aka registry), implementing DNSSEC or what means 1 billion transactions a day.

I really look forward to start there, and in the same time wish all the best to the Secutix team !

Dealing with old SSL certificats (algorithm check failed: MD2withRSA is disabled)

2010-08-02T11:19:00.004+02:00

I faced the problem of SSLHandShakeException, or "algorithm check failed: MD2withRSA is disabled" when upgrading above java 1.6.0_17.

The source of problem is well known, the MD2withRSA has been removed from the JVM because it is no more secure (References : CVE-2009-2409 deprecate MD2 in SSL cert validation, Sun java 1.6u17 release notes).

Lot of posts around the problem give the solution to update the certificate to use another signature algorithm, for example SHA1withRSA.

But what to do when the certificate is not under our hands ?

I will try to explain the problem and how I solved it.

Analyse the certificate's chain

First of all is to analyse the chain of certificate to see which one is using the deprecated algorithm.

The following command will print all the certificates in the chain and store them under the names level0.pem, level1.pem and so on.

openssl s_client -showcerts -connect xxxxxxxxxxxxxxxxx:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("level" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in level?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

The output given in my case :

Cert1, serial=xxxxxxxxxxxxxxxxxxxxx
subject= xxxxxxxxxxxxxxxxxxxxxxxx
issuer= /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
Cert2, serial=30000002
subject= /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Cert3, serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

We have a chain of 3 certificates, Cert1 signed by Cert2 signed by Cert3 signed by Cert3 (selfsigned).

Note : the first error here is that the webserver gives explicitly the entire chain of certificates. Thus the change of any root certificate provided by the jre will not be taken into account automatically.

Digging into the details of the third certificate (openssl x509 -in level2.pem -text) show that this certificate is signed with the old algorithm :

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT

So not only the way of providing the full chain is wrong in point of view of the server configuration, but the last certificate was never updated and thus still use the deprecated signature algorigthm.

Correct the certificate's chain

Now we have identified the weak link of the chain, what's the next step ?

The key point here is to correct the certificate's chain in order to make it more compliant to the standards :

As the third certificate is a well know root certificate (named verisignclass3ca in the jre cacerts), a working version of it is provided in the cacert of java sun (debian oriented commande line, with "changeit" as password) :

keytool -keystore /etc/java-6-sun/security/cacerts -exportcert -alias "verisignclass3ca" | openssl x509 -inform der -text

will output :

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 2 23:59:59 2028 GMT

which is the same as before, but with sha1WithRSAEncryption instead of md2WithRSAEncryption.

Thus we can simply remove it from the chain and validate normally the certificate's chain with only Cert1 and Cert2. The validation from Cert2 to "verisignclass3ca" will be automagically done.

To be able to do this, we need to create a custom X509TrustManager which will behave the following :

if the certificate's serial is the one of Cert1 (serial=xxxxxxxxxxxxxxxxxxxxx), then remove the last certificate of the chain and revalidate.
In all other cases, validate normally the certificate's chain.

Thus the custom X509TrustManager act as delegate, with one little variation (note : if someone know a easier way to instantiate the default TrustManagerFactory of TrustManager, please leave me a comment). Refer to my article about blind SSL factory for httpClients to see how to pass a custom TrustManager to a SSL factory.

My custom X509TrustManager class will finally look as the follow :

public class CustomX509TrustManager implements X509TrustManager {

   X509TrustManager delegate = null;

   public CustomX509TrustManager(KeyStore keystore) throws NoSuchAlgorithmException, KeyStoreException, CertificateException {
    // Instantiate the default X509TrustManager
    TrustManagerFactory factory = TrustManagerFactory
           .getInstance(TrustManagerFactory.getDefaultAlgorithm());
       factory.init(keystore);
       TrustManager[] trustManagers = factory.getTrustManagers();
       if (trustManagers != null && trustManagers.length > 0) {
           for (int i = 0; i < trustManagers.length; i++) {
               TrustManager trustManager = factory.getTrustManagers()[i];
               if (trustManager instanceof X509TrustManager) {
                   delegate = (X509TrustManager) trustManager;
                   break;
               }
           }
       }
       if (delegate == null) {
           throw new CertificateException("Cannot found any instance of X509TrustManager");
       }
   }

   public X509Certificate[] getAcceptedIssuers() {
    if (delegate == null) {
        return null;
    } else {
        return delegate.getAcceptedIssuers();
    }
   }

   public void checkClientTrusted(final X509Certificate[] c, final String a)
                   throws CertificateException {
       if (delegate != null) {
        delegate.checkClientTrusted(c, a);
       } else {
        throw new CertificateException("Unable to validate this certificate (delegate is null).");
       }
   }

   public void checkServerTrusted(final X509Certificate[] c, final String a)
                   throws CertificateException {
    if (delegate != null) {
           // hardcoding test to be sure we are trying to validate the right certificate
           if (c.length == 3 && c[0].getSerialNumber().toString(16).equals(BADCERTIFICATESIGNATURE)) {
            c = new X509Certificate[] {c[0], c[1]};
           }
           delegate.checkServerTrusted(c, a);
    } else {
        throw new CertificateException("Unable to validate this certificate (delegate is null).");
    }
   }

   private static final String BADCERTIFICATESIGNATURE = "xxxxxxxxxxxxxxxxxxxx";
}

With this implementation I'm sure that the my invalid certificate will continue to work, and it cannot be faked (as it could be with a completely blind TrustManager). But I can also expect that when the provider will update its certificate, everything will continue to work as expected because all other certificates are still validate the regular way.

Java and certificate's mess : blind SSL factory for commons httpClient

2010-08-02T08:53:00.003+02:00

There are parts of Java which are not very "quick development" oriented. The side I want to illustrate here is dealing with SSL.

When the application is in early development stage, we don't want to bother with stuff like valid certificate. We don't want to get stuck for days because we haven't received valid development SSL certificate from Verisign or other "more trusted than me" monopoles. We just want to activate the "--no-check-certificate" à la wget, or "CURLOPT_SSL_VERIFYPEER" à la PHP.

Adding a new certificate in the cacert file is not so complicated, but it is not always possible on every computers (should developers have administrators rights on their computers ?), or break the debian pakage integrity and risk to be overridden at the next JRE update.

No, for development phase, a blind SSL factory is a good point for productivity. Simply DO NOT FORGET TO REMOVE IT in the integration or pre-production phase. Having valid and trusted SSL certificate in production is NOT an optional thing.

What is a blind SSL factory

A blind SSL factory is simply an SSL factory which will validate any certificate. Expirated, selfsigned, but also man-in-the-middled or forged certificates will be trusted.

Mike McKinney already explained how to create a blind SSL factory for LDAP connexions.

I will leverage his explanations to enable blind SSL factory for commons httpClient.

The start point is to create a TrustManager which will trust any certificate, and then give this TrustManager to the SSL factory. This will result in a blind SSL factory :)

Anonymous class that implements X509TrustManager :

class BlindX509TrustManager implements X509TrustManager
{
   public X509Certificate[] getAcceptedIssuers()
   {
       return null;
   }
   public void checkClientTrusted(final X509Certificate[] c, final String a)
   {
   }
   public void checkServerTrusted(final X509Certificate[] c, final String a)
   {
   }
}

Initializing the SSLContext to retrieve a SocketFactory :

SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, new TrustManager[] { new BlindX509TrustManager() }, new java.security.SecureRandom());
SocketFactory blindFactory = sc.getSocketFactory();

And finally the BlindSSLProtocolSocketFactory which implements the needed ProtocolSocketFactory of httpClient :

public class BlindSSLProtocolSocketFactory implements SecureProtocolSocketFactory
{
   public Socket createSocket(String host, int port, InetAddress clientHost, int clientPort) throws IOException,
       UnknownHostException
   {
       return blindFactory.createSocket(host, port, clientHost, clientPort);
   }
   public Socket createSocket(String host, int port, InetAddress localAddress, int localPort, HttpConnectionParams params)
       throws IOException, UnknownHostException, ConnectTimeoutException
   {
       if (params == null)
       {
           throw new IllegalArgumentException("Parameters may not be null");
       }
       int timeout = params.getConnectionTimeout();
       if (timeout == 0)
       {
           return createSocket(host, port, localAddress, localPort);
       }
       else
       {
           return ControllerThreadSocketFactory.createSocket(this, host, port, localAddress, localPort, timeout);
       }
   }
   public Socket createSocket(String host, int port) throws IOException, UnknownHostException
   {
       return blindFactory.createSocket(host, port);
   }
   public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException, UnknownHostException
   {
       return ((SSLSocketFactory) blindFactory).createSocket(socket, host, port, autoClose);
   }
   public boolean equals(Object obj)
   {
       return obj != null && obj.getClass().equals(getClass());
   }
   public int hashCode()
   {
       return getClass().hashCode();
   }
}

Everything tied up together, put into the classpath of the application, will override the https protocol with the BlindSSLProtocolSocketFactory and thus allow your code to connect any certificate !

public class BlindSSLProtocolSocketFactory implements SecureProtocolSocketFactory
{
 private static final Log LOG = LogFactory.getLog(BlindSSLProtocolSocketFactory.class);
 public BlindSSLProtocolSocketFactory()
 {
     blindFactory = createBlindSocketFactory();
 }
 public Socket createSocket(String host, int port, InetAddress clientHost, int clientPort) throws IOException,
         UnknownHostException
 {
     return blindFactory.createSocket(host, port, clientHost, clientPort);
 }

 public Socket createSocket(String host, int port, InetAddress localAddress, int localPort, HttpConnectionParams params)
         throws IOException, UnknownHostException, ConnectTimeoutException
 {
     if (params == null)
     {
         throw new IllegalArgumentException("Parameters may not be null");
     }
     int timeout = params.getConnectionTimeout();
     if (timeout == 0)
     {
         return createSocket(host, port, localAddress, localPort);
     }
     else
     {
         return ControllerThreadSocketFactory.createSocket(this, host, port, localAddress, localPort, timeout);
     }
 }
 public Socket createSocket(String host, int port) throws IOException, UnknownHostException
 {
     return blindFactory.createSocket(host, port);
 }
 public Socket createSocket(Socket socket, String host, int port, boolean autoClose) throws IOException, UnknownHostException
 {
     return ((SSLSocketFactory) blindFactory).createSocket(socket, host, port, autoClose);
 }
 public boolean equals(Object obj)
 {
     return obj != null && obj.getClass().equals(getClass());
 }
 public int hashCode()
 {
     return getClass().hashCode();
 }
 private SocketFactory blindFactory = null;
 private static SocketFactory createBlindSocketFactory()
 {
     try
     {
         SSLContext context = SSLContext.getInstance("SSL");
         context.init(null, new TrustManager[] { new BlindX509TrustManager() }, null);
         return context.getSocketFactory();
     }
     catch (Exception e)
     {
         LOG.error(e.getMessage(), e);
         throw new HttpClientError(e.toString());
     }
 }
}

And to regirster the new protocol as the default https protocol :

Protocol.registerProtocol("https", new Protocol("https", (ProtocolSocketFactory) new BlindSSLProtocolSocketFactory(), 443));

Please note that if you want only access a selfsigned certificate you have better to use EasySSLProtocolSocketFactory from httpClient contibs. It still validate the selfsigned certificate, so expired or bad certificate will be denied.

Implementing unique constraints with Cassandra

2010-04-25T10:30:00.001+02:00

I was talking about my "Doodle clone with Cassandra backend" in a previous post, I want to explain a little bit how I implement 2 kinds of constraints with Cassandra.

Unique name constrain

When subscribing to a poll, a unique constraint on the name of the subscriber is applied. There is a first check in Javascript in the GUI, but there is also a check of the uniqueness of the names on the server side.

Before going deeper, I just need to say a word about the structure used :

To store the subscribers, I use a SuperColumnFamily, with the ID of the poll as key. For a poll having key "1234", it gives me something like :

"1234" => {
"subscriberKey1" => { name = "subscriberName1", options = ... }
"subscriberKey2" => { name = "subscriberName2", options = ... }
...
}

The trick about the subscriberKey* is to generate a unique ID based on a timestamp in order to be sorted by Cassandra.
The key will be something like : currentTimestamp - ClusterNodeId - ThreadId. Adding the ThreadId into the key give me the guarantee that using the System.currentTimeMillis() will be unique, because the processing will unfortunately take more than a millisecond :)

Using this key, I will write the subscriber row with ConsistencyLevel.QUORUM, and then I will read all the rows till the one I have inserted (with ConsistencyLevel.QUORUM again).
At this point I use Cassandra magic (rows are ordered) to be sure that I have selected all the subscribers they subscribe before the current one.
I remains me to check manually the uniqueness of the name. If another row has the same name, I will simply remove the current subscriber.

Limiting the number of subscribers per option

Another constraint I have implemented is the limitation of the number of subscribers per option.

The principle is the same as the unique name constraint : I count the number of previously inserted subscriber.
One point to keep in mind is that we can read a row with a duplicated name, which will be deleted later so it should not be taken into account for the actual constraint. This mean that we need to check if we are not counting duplicated names in this constraint too...

But the good news about this constraint is that it show a way to implement counters in Cassandra. Maybe I will write another post about this topic. The bad news is that we need to check the duplicated names in several places.

Limitation of the model

Complexity : adding more constraints grows the complexity in O(n^2), as every new constraints (duplicated names) should be implemented into every other constraints (limitation of subscribers per option).

Scalability : this model will scale very well for billions of polls with some tens of users. The inverse, some tens of polls with billions of users, needs a lot of resources for checking constraint, which will make the performance drop.

Doodle clone with Cassandra backend

2010-04-24T19:45:00.003+02:00

I follow Cassandra's activity for some months now, and I decided to try it. But what better than developing a small application to test real needs ?

That's what I did with my "Doodle clone with Cassandra backend".

What is Cassandra ?

According to the main page,

Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store

Why a Doodle clone ?

I'm working during my free time on an event manager software, so it was a good pretext to analyze Doodle business :)
It appears to be quite simple, so it was a good starting point.

Which features to implement ?

I added the following feature to the doodle clone :

Easy (easier) to create polls
Login free, secret key based administration
No options limitation
Email feedback when someone subscribe the poll (if email provided)
No duplicate name of the subscribers
An optional limitation of the number of subscribers per options

Have a look !

Go to http://doodle.noisette.ch and try it, the result is really surprising.

Disclaimer

There is absolutely no affiliation with Doodle, neither any idea to become the next Doodle. The goal of this application is purely academic, and it is deployed as is, without any guarantee.

Don't be abused by the term "commodity hardware"

2010-04-05T13:13:00.004+02:00

NoSQL paradigm claims to build clusters of "commodity hardware". But don't be abused by this term : "commodity hardware" is not your living room's computer. Commodity hardware is two slots' computer, 16+GB RAM, (ten)giga ethernet, raid5 hard disks.

Commodity hardware is not 500$ computers. It's 5000$ computers. But building a 10 nodes' cluster for 50'000$ is still really cheap.

And remeber : clusters' primary bottlneck is I/O. Both disk and network. So there is no place for virtualisation here.

Sequences scalability

2009-12-30T11:46:00.007+01:00

Sequences are central part of most computer systems. They are used both in technical part (generate unique identifier for object) and in business part (count the remaining free tickets which can be sold).

When the load on the application goes higher, sequences become quickly central bottlenecks of systems. So the goal here is to first categorize different types of sequences and then gives some keys to see how sequences be distributed to increase their scalability, and hence the global scalability of the whole system.

Characteristics of sequences :

Order : the number generate should be used in a given order (ascendant or descendant), or the order do not matter. I will talk about ordered or unordered sequence.

Missing values : some values can be missing in the sequence. For example the sequence miss the value 4 should not alter the behavior of the application. I will talk about continued or discontinued sequence.

Finite sequence : all the values of the sequence are know and countable. Countable sequences are particular case of finite sequence where the sequence has a reasonable amount of values, and thus could be represented by one object per values. I will talk about finite or infinite sequence, and countable sequence.

Key to distribute sequences

Discontinued sequences are easy to scale : the application can pick numbers n by n in the sequence, reducing the amount of calls to the sequence by n. Good example for of discontinued sequences are objects identifier generators.

Unordered sequences are also easy to scale : a counter can be decomposed in n subcounter, picking at random one of the subcounter to increment or decrement will reduce the contention on one counter by n. A typical example is a quantity of object to sell. N subcounters are initialized with the sum is the total amount to sell. The object cannot be sold anymore when every subcounters are at 0.

Countable sequences can be scaled by representing every value of the sequence as a single object in the database. Updating an unused object is a easy task.

Finaly infinite, continued ordered sequence are very hard to scale because synchronization between all callers is required, so a single point of contention is mandatory.

Conclusion

Sequences are choke point in most systems, but as we saw above they can scale relatively simply with two simple tricks : read number n by n instead of 1 by 1, or decompose a counter in n subcounters.

Call different services, use the first to reply

2009-11-15T20:44:00.006+01:00

The needs

My needs were the following : I have an arbitrary amount of webservices to call, but I don't know, for a particular query, which one will return the answer. More than that, some are slower and others are faster, but again, I don't know which is the fastest for my particular query.

So what I will do is to parallelize the queries, and use the value of the first which return my a good value.

Use an Executor

The first component to implement such a requirement is an Executor.

The Executor will run all my queries, in as many threads as I want, permitting to fine tune the behavior of the system.

As many queries will input the system and will be translated in many more threads, it is important to use a limited amount of threads to not crash the system.

Synchronization on result

A specific object will be used to synchronize the result : the first result will be returned to the caller, letting the running threads die, and no more threads will be run for this query.

Some basic primitive for concurrent programming (java.util.concurrent) will be used, such as CountDownLatch : the caller will block on the latch, and once a thread will find the answer, it will set the value into the result and count down the latch. The caller will be freed and the value will be available.

Watchdog if all the queries fail

One point to not forget is if every queries fail, the caller should be informed of this fail.

A watchdog will be used : it will block till all the threads executing the query will finish, and will then be run. Its only task is to free the caller. This one will continue the processing, but the result will not be available. This will be the responsibility of the caller to run user code to handle this special case.

Strong requirements

The requirements are the following :

Use as little synchronization as possible
Use as much concurrent primitives (java.util.concurrent) as possible
Do it as generic as possible

Java implementation

The interesting part of the implementation is given here below.

The Executor is simply an java.util.concurrent.Executor. I'm not good enough to implement a better solution than they do.

The result object is composed of the following attributes :

public class FutureResult {
private T result;
private boolean done;
private AtomicInteger threadCount = new AtomicInteger(0);
private CountDownLatch latch = new CountDownLatch(1);
}

A generic type for the value, a AtomicInteger to count how many other threads are working on this result, and a latch to make the caller wait.

The watchdog class will simply wait till all the threads are finish and free the caller if it is not already the case :

class WatchDogRunnable implements Runnable {
public void run() {
while (result.hasThreadsWorking()) {
synchronized (result) {
result.wait(2000);
}
}
latch.countDown();
}
}

And finally an abstract callable worker which can be easily extended to run the wanted tasks. The call function will increment the AtomicInteger, do the work if it is not already done, if a result is found, free the caller, decrement the AtomicInteger and return the value if it is set. Not that the worker implementation will implement the callInternal function.

public abstract class AbstractCallableWorker
implements Callable {
private FutureResult result;
public final T call() {
result.setOneMoreThread();
if (!result.isDone()) {
T callResult = callInternal();
if (callResult != null) {
setResult(callResult);
latch.countDown();
}
}
result.setOneLessWorkingThead();
return result.getResult();
}
protected abstract T callInternal();
}

Everything put together, you can implement as much worker as you want and call as many webservice as you want, with the only guaranty to get the caller continue with the fastest service to reply !

Clustering Jackrabbit 1.5.x with DataStore configuration

2009-11-14T21:36:00.004+01:00

Jackrabbit is the reference implementation of JSR-170 : JCR, Java Content Repository.

One day we felt the needs to run a Jackrabbit repository in a clustered environment for reliability. So a JCR runs on two separated servers, backed by the an Oracle db and a NFS shared datastore.

It exists some difficulties to run such architecture, mainly because both JCR nodes (JCR1 and JCR2) do not know each others. So if we insert some content on one node, it takes some time before we can read it on the other node.

In Jackrabbit 1.5.x, Session.refresh do not work correctly, so we need to do some trick to enable cluster (synchronization) features.

First of all, we add a custom ServletFilter which handle the GET (read) request and transform it on a HEAD one (test if the content exists) using apache.commons.HttpClient.

If the return of the query says the content exists, then we run the normal request. If the content do not exists, we way for some arbitrary time and relaunch the HEAD request.

This filter will let enough time to the node to synchronize itself, and then perform the query in the right way.

Other possibilities like HEAD on the current node and then HEAD on a different node should also be possible, but this will require every nodes to know about every other nodes. No the best idea.

One another tricky point is to store all the content to the configured datastore. Be carefull to not rely on a JNDI persistence manager, but be sure to use a subclass of a bundle persistence manager, otherwise you will have some surprise with the size of the database.

Des nombres à usage unique (nonce)

2009-01-17T18:24:00.007+01:00

Afin de répondre à une problématique de transmission d'informations sensibles sur un réseau pas sûr (Internet donc...), une solution est l'utilisation de nonce, diminutif de number used once, nombre à usage unique.

Ils sont utilisé pour mettre du sel dans des informations sensibles qui seront ensuite hashées et transmises en clair sur le réseau. Mais leur efficacité n'est effective seulement si on a la garantie qu'un même nonce ne va jamais être utilisé 2 fois !

Exemple type : vous développez un service d'authentification, mais celui-ce ne peut se faire sur du SSL. Vous souhaitez toutefois que si une personne intercepte les informations, elle ne puisse pas les réutiliser pour s'identifier à son tour.

Le seul hashage du mot de passe ne suffisant pas car la personne qui a interceptée le mot de passe hashé pourra rejouer la séquence pour simuler sa connexion, une solution est de hasher le mot de passe concaténé au nonce (du style sha256("#" + mot de passe + "#" + nonce + "#")), puis de transmettre le nom d'utilisateur, le nonce utilisé et le résultat du hashage. Le serveur disposera ainsi de toutes les informations pour vérifier si le mot de passe utilisé pour le hashage était effectivement correcte ou pas. Les prochaines requêtes faites avec ce nonce seront systématiquement refusées.

C'est pour faciliter l'accès à ces nombres que je mets à disposition un petit service de génération de nombre à unique, accessible publiquement à l'adresse

http://nonce.noisette.ch/next

Chaque appel à cette url retourne un chaine de 32 caractères composées des lettres a-z, A-Z et les chiffres 0-9. Notez que les chaines retournées sont donc senible à la casse.

Le nombre de nonce possible est donc (26+26+10)^32 = 2.27 * 10^57, soit à peu près 6-parasite, ou beaucoup plus que d'atomes dans l'univers.

A utiliser sans modération pour toute application nécessitant la transmission d'informations sensibles sur un réseau non sécurisé.

Edit (06.01.2011) : GAE ne supporte plus le proxying, vous pouvez essayer l'app directement sur http://noisette-nonce.appspot.com/.

Implémentation d'un serveur proxy HTTP

2008-06-08T20:00:00.000+02:00

La question à la base de cet article est la suivante :

Comment faire pour que mes concurrents ne soient pas au courant que j'observe (très) régulièrement une section particulière de leur site internet ?

La première étape bien évidemment est de la légitimer cette question. Comment un concurrent pourrait savoir que je consulte régulièrement son site ?

La réponse est simple. Prenons un cas concret pour illustrer : ELCA Informatique possède les plages d'adresses ips 193.72.144.0 - 193.72.147.255 (bloc /22 = 1024 ips, hosté chez Cablecom) et 193.73.238.0 - 193.73.238.255 (bloc /24 = 256 ips, hosté chez Sunrise)

Ce genre d'info se trouve très facilement via un mélange whois, traceroute et autres informations DNS.

Une fois qu'on a ces ips, il suffit de rechercher dans les logs les hits faits par ces ips et on pourra dresser un profil précis des intérêts des collaborateurs d'ELCA sur notre site.

Donc comment faire pour éviter cette traçabilité ?

Connexion Internet à adresse ip dynamique (xDSL)

Une première solution est d'utiliser une connexion xDSL pour toutes les connexions humaines à Internet, et de dédier exclusivement les plages d'ips fixes et repérables aux services de l'entreprise. Cette pratique est de plus en plus courante, surtout avec l'arrivée des connexions VDSL et de boitiers qui permettent d'agréger plusieurs lignes xDSL afin d'une part d'avoir un redondance, et d'autre part de partager la somme des débits des lignes entre les utilisateurs. Le seul détail concernant cette solution est de vérifier que l'adresse ip change réellement, faute de quoi il faudrait forcer ce changement.

Serveur proxy

Une autre solution, que je vais détailler ici car elle est plus intéressante d'un point de vue ingénierie informatique, est de faire passer le traffic des utilisateurs par un proxy. Par proxy j'entends tout type de connexion indirect à Internet, donc autant les serveurs proxy HTTP, SOCKS, etc que les réseaux de proxy comme par exemple Tor.
Le fait d'accéder à Internet par l'intermédiaire d'un proxy permet de visualiser un site avec une adresse ip qui n'est pas notre, mais appartient à un prestataire de ce genre de service. Cependant l'anonymité à 100% n'existe pas : il existera toujours un intermédiaire qui saura qui a accédé où. La confiance des intermédiaires est donc de mises dans cette configuration.

Il existe une grande quantité de serveur proxy logiciel de qualité, open source ou commercial, comme par exemple Squid, Privoxy, Apache mod_proxy, etc... Mais une fois de plus, l'utilisation d'un logiciel existant nous priverait du plaisir de développer de notre propre implémentation.

Principe de base

Le principe d'un serveur proxy est donc d'intercepter la requête d'un navigateur, d'ouvrir une connexion vers le site cible, transmettre la requête original, lire le résultat et finalement renvoyer ce résultat au navigateur.

Protocole HTTP

La partie centrale d'un serveur proxy HTTP réside sa compréhension du protocole HTTP. Celui-ci comporte des particularités qui vont être détaillées.

Le serveur proxy va recevoir une requête du navigateur, dont la première ligne comporte l'action à exécuter, l'url de la cible et une éventuelle version du protocole utilisé :

GET http://www.noisette.ch/ HTTP/1.0

Cette première ligne va donc directement nous renseigner sur le serveur cible à connecter. Le reste de la requête est composée de lignes de header, contenant diverses informations sur la requête comme le navigateur utilisé ou le referer (en français on dit comment ?).

Transfer de la requête au serveur cible

La prochaine étape est le transfert de la requête au serveur cible. A ce moment on peut éventuellement modifier ou enlever des headers du client, voir en ajouter d'autres. Plus précisément, il peut être intéressant de filtrer tous les headers des clients qui pourraient trahir l'utilisateur du proxy (information leakage).
Reste la lecture du résultat, qui n'est de loin pas la partie la plus triviale.

Ne pas bufferiser la lecture du résultat

L'implémentation d'un serveur proxy dans laquelle on lit le résultat en entier (via un lib du style httpclient) avant de l'envoier ensuite au navigateur n'est à mon avis pas bonne : le délai entre la requête et la réponse risque d'en prendre un coup, surtout pour les grosses pages.
L'idée est donc de retourner directement les bytes lus du serveur web au client.

En pseudo code, ca donne quelque chose du style :

 // fromWeb : InputStream du socket de la connexion vers le serveur source
// toBrowser : OutputStream du socket de la connexion vers le browser
while ((i = fromWeb.read(buffer)) != -1) {
  toBrowser.write(buffer, 0, i);
  toBrowser.flush();
}

Fermeture des connexions

La fermeture des connexions est très importante afin de libérer les ressources et ne pas avoir un serveur qui explose après 20 requêtes. Facile en théorie, la fermeture de la connexion est la sous partie non triviale. Dans la mesure où le serveur ne ferme pas systématiquement la connexion à la fin du transfert si il reçoit un header "Connection: keep-alive", il faut détecter quand la réponse du serveur est complète pour pouvoir fermer la connexion.

Dans une grande majorité des réponses, la taille de la réponse est spécifiée via un header "Content-Length: 82". Il suffit donc de lire autant de bytes que nécessaire et la connexion peut être fermée. Mais quelques réponses ne vont pas retourner de taille. C'est le cas par exemple lors du streaming d'un fichier. Dans ce cas il faut lire la réponse jusqu'à ce que le serveur ferme lui-même la connexion.

Transfer-Encoding: chunked

Une autre difficulté à la lecture de la réponse est l'encodage chunked. Dans ce mode de transfert, le serveur sépare la réponse en plusieurs parties, les chunks. Ca lui permet d'envoyer une partie de la réponse tout en calculant la suite. Par exemple Google utilise ce mode de réponse : les 2-3 premiers résultats sont dans un cache direct, et Google les retourne dans un premier chunk. Puis il doit aller chercher les 7-8 autres dans un deuxième cache, opération un peu plus coûteuse, qui se fait pendant que le navigateur du client lit ce premier chunk. Ca permet au serveur de ne pas attendre d'avoir entièrement cherché les 10 résultats, et de profiter du temps de transfert avec le client. Du point de vu du client, une fois qu'il a fini de lire le premier chunk, les suivants sont prêts à être lus. L'impression de fluidité est donc parfaite. Mais malheureusement peu d'implémentations tirent intelligemment profit de ce type de transfert.

En pratique, la réponse d'une encodage chunked donne quelque chose du style :

taille du chunk en hexa \r\n
données \r\n
taille du prochain chunk \r\n
données \r\n
...
0\r\n
\r\n

Pour lire la réponse, il faut donc lire la taille du chunk, lire les données du chunk, lire la taille du prochain chunk, etc jusqu'à ce qu'on ait un chunk de taille null, signifiant la fin de la réponse.

HTTP/1.1 200 OK¶
Date: Fri, 31 Dec 1999 23:59:59 GMT¶
Content-Type: text/plain¶
Transfer-Encoding: chunked¶
¶
1a¶
abcdefghijklmnopqrstuvwxyz¶
10¶
1234567890abcdef¶
0¶
¶

Caching

Prochaine étape dans l'implémentation d'un serveur de cache utile est efficace, c'est l'ajout d'une couche de cache au niveau du proxy : le serveur cible va retourner une information sur la date de dernière modification de la page. Cette indication peut être utilisé pour retourner la page mise en cache plutôt que de relire la réponse du serveur.

Authentification

Dernier point important si on met un serveur proxy sur internet, il faut ABSOLUMENT implémenter un ACL (access control list) afin de restreindre l'accès et l'utilisation du proxy aux personnes authentifiées uniquement. Faute de quoi votre tout beau serveur proxy sera vitre trouvé et utilisé par des personnes malveillantes pour spammer, consulter des sites illégaux etc.

Prochaine étape : au travail !

Mettre à mal un réseau d'entreprise avec Outlook (TM, R & CO)

2008-06-05T06:21:00.004+02:00

Suite à une expérience involontaire d'un collègue de travail, on a eu 30 ordinateurs bloqués une quinzaine de minute :

Notre serveur SVN envoie un mail à chaque commit à une mailinglist interne, à laquelle une trentaine de collaborateurs est abonné. Le commit incriminé était certes quelque peu conséquent, une colonne ajoutée dans un fichier CSV de 5000 lignes, mais la conséquence était désastreuse !

Le mail faisait ~ 5Mb, et le diff du commit était formaté en HTML. Tous les collaborateurs qui ont cliqué sur le mail avec le preview activé n'ont pas eu d'autre choix que de tuer Outlook après avoir eu l'ordinateur bloqué un bon moment.

Moi qui n'était déjà pas un grand amoureux d'Outlook et de son immense capacité à accomplir des recherches performante parmi les mails, me voici comblé.

Mais pourquoi donc autant d'entreprise s'accrochent-ils à ce logiciel ? Dans tous les cas, si vous voulez forcer un peu la main pour le passage à un autre logiciel, vous savez ce qu'il reste à faire.

Une liste de USER AGENTS parsable

2008-02-23T13:42:00.000+01:00

Il est toujours utile d'avoir sous la main une liste de USER AGENTS facilement parsable.

La mienne, qui ne contient que des USER AGENTS ^Mozilla/.* se trouve à l'adresse http://www.noisette.ch/useragents/. Elle est mises-à-jour journalièrement sur la base des navigateurs qui se connectent sur mon serveur, tous sites confondus. Elle va donc suivre l'évolution des numéros de version des Firefox et autres IE...

Cette liste, couplée à la fonction url_get_contents définie antérieurement, permet facilement de disposer d'un USER AGENT pour faire ce qu'il est possible de faire avec un USER AGENT généré :)

Illustration en PHP :

$useragents = explode("\n", url_get_contents('http://www.noisette.ch/useragents/list.txt'));
$useragent = $useragents[rand(0, count($useragents) - 1)];

De la concurrence des requêtes SQL

2008-02-18T12:53:00.000+01:00

Sans cité Montaigne, voici un cas académique dans lequel la concurrence des requêtes SQL est souvent oubliée.

Nous avons une table hits qui contient 4 champs : une date (nommé date), une clé étrangère pointant vers un objet du système (nommée object_id) et un compteur implémenté sous ca forme la plus simple : un entier (nommé counter). Puisqu'on travail avec une framework qui implémente de l'active record on ajoute un champ id qui fera office de clé primaire.
A chaque utilisation de l'objet référencé par la clé étrangère on souhaite incrémenter le compteur et recommencer à 0 tous les minuits afin d'avoir un historique journalier de l'utilisation de l'objet. Alors comme on a quand même un peu réfléchi à la performance du système (un billet sur le sujet est en préparation), on définit un index composé des champs date et object_id. Puis on définit la fonction suivante, donnée ci-dessous en pseudo-code, qui incrémente notre compteur et insère un nouveau tuple si aucun n'existe pour le jour courant :

void function hit ( int $object_id ) {
  SELECT FROM hits WHERE object_id = $object_id AND date = NOW()
  if (row_exists)
      UPDATE hits SET counter = counter + 1 WHERE  object_id = $object_id AND date = NOW()
  else
      INSERT INTO hits (object_id, date, counter) VALUES ($object_id, NOW(), 1)
}

Tout se passe bien jusqu'au jour où on se rend compte qu'il y a plusieurs lignes par objet et par jour dans la base de données.

Ce problème vient du fait qu'il peut se passer un temps indéterminé entre la requête SELECT et l'INSERT. Si à 00h01 2 requêtes sont faites en même temps sur le même objet, il est fort probable que 2 requêtes SELECT soient faites avant un INSERT, et donc les 2 tests if (row_exists) vont retourner faux et 2 INSERT seront fait.

Les solutions pour résoudre ce problème sont multiples, elles passent de la redéfinition de la clé primaire en date, object_id plutôt que notre champ id, ce qui aurait comme comportement de faire échouer le 2ème INSERT, erreur qui pourrait être capturée et traitée spécifiquement. Une autre solution serait de mettre un verrou sur la fonction, chose très aisée en Java avec le mot-clé synchronized. La fonction deviendrait void synchronized function hit(int object_id), évitant ainsi ce type de problème de concurrence.

Dans tous les cas les applications web sont aussi (voir même plus) soumises aux problèmes de concurrence, et l'expérience nous montre que la technique de l'autruche de même que les phrases du style "Il ne PEUT PAS y avoir 2 requêtes en même temps" sont à bannir absolument.

Vos données sont-elles réellement privées ?

2008-01-29T11:16:00.000+01:00

Donnez des informations pour exister

Le principe premier du Web 2.0 est la participation des utilisateurs. Pour les sites sociaux comme MySpace et Facebook, où la participation se calcule en quantité d'informations données sur soi-même.

Collecte indirecte d'informations

L'aspect de collaboration entre les membres résulte en une masse d'information indirecte enregistrée souvent au dépend de la personne ciblée :

Facebook par exemple enregistre des informations sur vous par rapport aux détails que donnent vos amis (appelé Social map) : à chaque ajout de nouvel ami, vous avez la possibilité de spécifier comment vous l'avez connu. Grâce à ce système subtile, mon profile Facebook sait maintenant que j'ai fini l'EPFL en 2007, que je fais partie d'autres associations, ... alors que je n'ai rien renseigner sur ces sujets précis.

Le business des données personnelles

Le fait d'être encouragé à compléter son profil qui n'est complet qu'a 88% comme nous l'indique de manière bien visible Linkedin n'est pas entièrement désintéressé : le fait de connaitre précisément ses utilisateurs et d'en dresser des profils augmentent largement les marges sur les revenus publicitaires qui seront mieux ciblés donc plus percutant donc plus intéressant pour l'utilisateur. Revenus publicitaires qui sont, rappelons-le, le business model principal des ces sites sociaux.

Protection des données

L'aspect à ne pas perdre de vu si on utilise ce genre de sites, c'est que ça n'est pas une simple cas à cocher "Rendre mon profil privé" qui protègera réellement les données de votre profile : les données sont chez une personne tierce qui d'un jour à l'autre peut décider d'en faire autre chose. Ou, comme c'est le cas sur MySpace, une vulnérabilité du site permet d'outerpasser cette coche ridicule...

La réponse au titre du billet est clairement NON ! Le fait de déposer vos données sur un service externe quelconque ne les rendent pas privées. Donc soit vous ne mettez que des informations réellement publiques sur votre profil, soit vous faites confiance à 100% au service et vous ne vous demanderez pas d'où viennent les données sur vous retrouvées dans la nature...

Ils en parlent

Faille de sécurité qui perment de voir les photos privée d'un profil sur Myspace : http://www.wired.com/politics/security/news/2008/01/myspace_torrent
Nos données personnelles sur Facebook : http://standblog.org/blog/post/2008/01/10/De-lavenir-de-Facebook-et-de-nos-donnees-personnelles
Système de publicité intrusive sur Facebook : http://www.infos-du-net.com/actualite/12304-facebook-publicite-internautes.html

Je télécharge mes MP3 et les écoute légalement.

2007-12-30T22:39:00.000+01:00

Le parlement et le conseil national ont accepté le 5 Octobre 2007 presque sans aucune résistance une loi fédérale sur le droit d'auteur et les droits voisins.

Pour toute question à propos du référendum lancé, que dit en passant j'encourage fortement à signer, rendez-vous sur le site No Swiss DMCA.
Je n'essayerai pas non plus de déterminer à quelles mesures techniques, notées efficaces, le texte de loi fait peut bien faire référence.

Cette loi, plus précisément l'article 39a alinéa 4 donné ci-après, combiné à l'approbation du Tribunal fédéral (TF) sur l'introduction d'une redevance sur les supports numériques (baladeurs MP3, iPod et autres enregistreurs à disques durs) entrée en vigueur au 1er septembre 2007, me mène à la conclusion suivante :

Je vais télécharger de la musique sur mon réseau peer-to-peer préféré, ripper des CDs et retirer les DMA de mes MP3 restants (autrement dit : contourner les mesures techniques efficaces) et l'écouter (exclusivement) sur mon baladeur MP3 récemment acquis. Celui-ci étant taxé, je m'affranchis de toute autre taxe, et je deviens entièrement légal. Idem pour les divx !

Art 39a
4 L’interdiction de contourner ne peut pas frapper celui qui contourne une mesure technique efficace exclusivement dans le but de procéder à une utilisation licite.

PS : cet article n'est pas illégale au sens de l'Art 39a 3a, c'est-à-dire que cet article ne fait pas promotion visant à contourner des mesures techniques efficaces.
PPS : la critique de la double imposition à une taxe sur les droits d'auteurs des musiques achetées sur un online music shop et écoutées sur un baladeur taxé fera l'objet d'un autre article.

Offrir un réseau wifi ouvert pour rentabiliser sa connexion Internet

2007-12-30T22:31:00.000+01:00

J'écrivais il y a un bon moment comment un administrateur réseau peu scrupuleux pouvait arrondir ses fins de mois en détournant les publicités des sites visités par les utilisateurs
interne.

Cette technique s'adapte très simplement à un réseau wifi ouvert...

Mais attention au click through rate trop élevé :)

Twitter, un vrai service Web 2.0 (le retour)

2007-12-15T16:14:00.000+01:00

Pour commencer j'ose espérer que le 2ème degré du message précédent a été perçu.

Twitter est selon moi un vrai service Web 2.0, c'est-à-dire qu'il ne sert à rien. On n'est pas plus heureux en l'ayant découvert et ça ne fait pas avancer la société de l'utiliser.

Mais au-delà de considération subjectives à son sujet, les technologies et les techniques d'addiction mises en oeuvre sur ce site sont suffisamment intéressantes pour être discutées ici :

Premièrement les méthodes de publication disponibles sont autant multiples que variées :

Interface web,
SMS,
IM (client jabber),
...

On voit d'entrée que le service est fait pour être mis-à-jour en permanence, très facilement par IM quand on est devant un ordinateur relié à Internet, mais aussi via des dispositifs mobiles une fois le clavier de l'ordinateur hors de porté. Ainsi un utilisateur peut à tout moment renseigner ses lecteurs virtuels et potentiels sur ce qu'il est en train de faire. L'aspect mise-à-jour via téléphone portable est très important, car il permet de modifier le statut lors des sorties, donc quand c'est le plus croustillant.

Un aspect important pour renforcer l'addiction est la possibilité d'émettre un rappel (SMS ou email) en cas de non mise-à-jour prolongée.

Deuxièmement les différents formats de lecture possibles sont aussi standard que tendance : on retrouve ainsi la "social timeline" sur sa page personnelle au style très épuré Web 2.0 et le fameux flux RSS. La communauté de lecteurs n'est pas en reste non plus, avec son lot de features pour se créer un réseau d'amis.

Pour conclure sur cet article plutôt bullshit'stisant pour reprendre les termes d'autres, je dirais que mis à part le côté "sert-à-rien" il pourrait remplacer à merveille les blogs que les jeunes s'efforcent d'utiliser de la manière dont Twitter oblige, la possibilité de mettre les photos en mois. Et que le côté publication d'activité via IM est réellement bien fait.

Twitter, un vrai service Web 2.0

2007-12-15T13:24:00.000+01:00

D'abord il y a eu les blogs, qui permettaient de raconter sa vie
passionnante de tous les jours, puis maintenant il y a Twitter, qui force de
résumer sa vie passionnante en 140 caractères.

Comme je n'ai pas une vie passionnante, 140 caractères sont longtemps suffisant pour expliquer que je vais au travail, je suis bloqué sur un problème en PHP, j'ai vu un site super, j'ai mangé au Delectis à midi et que "Tien, c'est déjà 16h30 alors je vais rentrer".

Donc je vous invite tous à retrouver le fil RSS de ma vie La vie au format RSS de Benoit Perroud.