Déployer un war dans tomcat sur openshift

Pour déployer un war tomcat sur openshfit le moyen le plus simple que j'ai trouvé est d'utiliser l'image S2I (Source-to-Image) de Sarcouy. Vous verrez dans l'exemple que je présente qu'il n'est pas nécessaire d'utiliser un repository git.

On va donc procéder avec les étapes suivantes :

1. Créer un projet openshift my-experiences
2. Creer un projet maven my-app pour faire un war, mais cela peut être votre code existant.
3. Créer un imagestream tomcat-builder qui embarque le builder de Sarcouy
4. Creer un imagestream my-tomcat-app qui va recevoir l'image produite par le builder
5. Creer le builder 
6. Lancer un build qui va alimenter l'imagestream my-tomcat-app
7. Créer une application à partir de l'imagestream my-tomcat-app

Creer un projet maven my-app pour faire un war

oc new-project my-experiences
mvn archetype:generate \ 
   -DarchetypeGroupId=org.apache.maven.archetypes \
   -DarchetypeArtifactId=maven-archetype-webapp \
   -DarchetypeVersion=1.3 \
   -DgroupId=fr.maker.paas \
   -DartifactId=my-app \
   -Dversion=1.0-SNAPSHOT 
# verifier que ça construit bien 
cd my-app && mvn package

On crée les imagestream necessaires

oc create imagestream tomcat-builder
oc import-image --from=sarcouy/s2i-tomcat:8.5-jdk8-mvn3.3.9 tomcat-builder
oc create imagestream my-tomcat-app

On crée le builder

On utilisera le paramètre --binary qui nous permet de ne pas utiliser un repo mais de donner en paramètre de lancement le répertoire du code source

#ceci va créer le buidconfig my-tomcat-app qui 
#par défaut récupère le nom de l'imagestream de destination
oc new-build --image-stream=tomcat-builder --binary --to=my-tomcat-app
# le builder de sarcouy nous impose de préciser le nom du war a déployer 
# en variable d'environnement
# je suppose qu'il a du tomber sur des projets qui fabriquaient plusieurs war
# on patch donc le buildconfig 
# vous pourvez aussi utiliser aussi oc edit
oc patch bc my-tomcat-app -p \
  '{ "spec" :{"strategy":{"sourceStrategy":{ "env" : [{"name":"WAR_NAME", "value": "my-app.war"}] } } } }'

On lance le build qui va créer l'image et la mettre dans l'imagestream de destination

oc start-build my-tomcat-app --from-dir=/vagrant/lab/05_builder/tomcat/my-app/ --follow

Ceci construit et pousse l'image dans la registry interne d'openshift, et toute image dans la registry interne est aussi une imagestream. Donc l'image est ici le tag latest de l'imagestream my-tomcat-app.

On déploie

oc new-app --image-stream=my-tomcat-app
#on expose pour la rendre accessible depuis internet
oc expose svc/my-tomcat-app

A chaque fois qu'on relancera un build le deploymentconfig qui référence cet imagestream détectera le changement et redéploiera automatiquement l'image.

Understanding kerberos

Kerberos allow different nodes of a network to authenticate to each other even if this network is not secure. Not secure means that eavesdroppers are listening on the network and may catch your data to fake your identity.

I didn't find easy to understand this protocol and why it was designed in such way, so I decided to build my own tutorial.

My main source of inspiration was this two links : microsoft technet  and the RFC 

Let's start with two nodes that want to authenticate to each-over.

A naive solution would be sharing a secret password

A emit an authent request to B accompagnied with password that A and B share. 

B check the password and authenticate A. 

The problem is eavesdroppers. They're listening on the network, if they catch the password they can build the authent request for them and fake the identity.

 

Is there a solution to this problem ? The answer is yes : Symetric Encryption ! Symetric encryption is the process of encoding messages with a key (a sequence of bytes) in such a way that you can only decode it if you also have this key.

 A and B share the same secret key that they never send in clear over the network. Let's call this key Kab.  

We could build the message to authenticate this way : Authent Request + A + Encypt(Kab, Timestamp)

When B receive an authent request from A he uses the key Kab to decode the timestamp, if  he finds a valid timestamp he authenticates A. The timestamp is used to prevent an eavedropper to just resend the whole packet to B, because B will accept the authent request only if the timestamp is recent enough. We could even imagine that B will never accept twice the same timestamp from A.

With this process an eavedropper is unable to build a valid authent request.

Mutual authentication is even feasible with B resending the timestamp sent previously by A.

But it could be a problem because the eavedropper have now the timestamp and its encrypted version so it can start to search a key by brute forcing. Thus some random data are added before encryption.

B was able to split timestamp and random data, it's a proof for A that B has also the key Kab.

How this solution scale ? 

But this solution does not scale well. Each node have to share a key for each relation. For instance in a network with A, B, C, and D the node A will need to maintain 4 keys Kab, Kac and Kad to manage all the authentications with the other nodes and the node B will have to maintain Kab, Kbc and Kbd, and so on for C and D. 

An other problem occur when you need to add or remove a node in the network. The new node has to notify all the other nodes in order to share with them a key, it may involve a lot of exchange between node that potentially will never need to communicate anyway. 

And what happen if one of them is inactive or unvailable, when the new node is arriving in the network, they'll have to synchronize lately ? 

The  kerberos protocol

To solve this problem the kerberos protocol propose a solution. Each node share its key with a special node called the KDC (Key Distribution center). All the node sharing a key with the KDC make a group called realm.

So what happen when A want to authenticate with D for instance ?

(1) A ask the KDC he wants to athenticate with D
(2) KDC return a message containing a Kad key (called session key) encrypted with the Ka key (called the long term key) so that only A can decrypt it. Along the message there's also the Kad, with the requester and a validity timstamp encrypted with Kd. A cannot decrypt this message as he doesn't know the Kd key. Thus he'll only be able to resend it. This part is called the kerberos ticket.
(3) A send its authent request, with the kerberos ticket and a timestamp encrypted wit Kad if A want mutual autehntication.
(4) D use its Kd key to find Kad, the requester (A) and the validity of the request. If the requester and the validity match then the authentication is accepted. Now A and D share the same Kad key. D may use it to decrypt the timestamp  and resent it to A for mutual authentication.

A big difference wih other protocols like NTLM for instance deserve to be noted here : D don't need to connect to the KDC. The authentication of A could be validated with the information provided by the client.

The ticket granting ticket (TGT)

Actually the nodes in the system are separated between two populations : 

1. The services. The services is what's behind a server software like print server, web server, shared file system and so on. 
2. The users. The users is usually human being constantly connecting and disconnecting the network.

For the services the easiest way to share the keys is to copy the key between the KDC and the service. As the services are numerically much fewer than users and  stay on the network all the time it's fine. Beside we control what's installed on the servers which is not the case with the users. 

For the users the key is derived from their password. Both the client and the KDC derived the key from the password.

• When the logon succeed the kerberos client calculate a cryptographic key from the password. This key is the long term key and is put in a secure volatile cache storage. 
• The KDC also calculate a cryptographic key from the password, the algorithm calculation is the same thus the key is the same on both side. 
• Notice that no password is exchanged between the workstation and the KDC on the network.

But we have two security problems ... 

• The key Ka is a long term key. Every time A request an authentication the key Ka must be used. Then it's "easy" for a virus, a malware, any user who use the A session to get this long term key and then get a long term ability to connect to any service on the network that A was able to connect
• When A request a kerberos ticket for D to the KDC, we must implement a pre-authentication mechanism. Otherwhise anybody could submit a request in the name of A. It should be ok as the response is encrypted with A's key thus only usable by A. But things are not so simple because the response also contains plaintext field that can be used to optimise a brute force attack on the key. Especially when the key is derived from a user password.

The solution is to create a special kerberos ticket called TGT (Ticket Granting Ticket) after the client successfully authenticate to the KDC.

The TGT is the ticket the client use for the KDC. It last about 8 hours (a logon session) and contains a session key for the communication between the client and the KDC, thus not using anymore the long term key. The long term key is used only during the authentication and is dropped from the memory.

This lead us to split the KDC into 2 different component :

1. The authentication System (AS) that give a TGT to the client (TGT is a special kind of kerberos ticket for the KDC itself). 
2. The Ticket Granting Service that give a kerberos ticket to the client for authenticating to the sevice

The AS hold the keys of the users (derived from the password) while the TGS hold the keys of the services : 

Now we can make the big picture :

If you want now to practise I advice to follow this tutorial on manula blog where you create a user, a KDC and a service. It's the opportunity to make the relation between the component/action and the big picture.

Comprendre les problèmes d'encoding en java

Il m'arrive souvent d'intervenir sur les problèmes d'encoding. Le constat que je fais c'est que la plupart du temps les équipes connaissent mal les concepts autour de l'encoding, ce qui rend le debuggage laborieux.

Pourtant ça n'a rien de bien compliqué. Je vais d’abord vous faire un petit rappel des concepts puis ensuite je vous montrerai quelques exemples d'accidents, en général une fois qu'on a compris ce qu'il se passait la résolution n'est plus très loin.

2 concepts majeurs: l'encoding et la table des symbôles

La table des symbôles

La table des symbôles n'est pas un concept informatique à proprement parlé il s'agit d'un tableau ou pour être plus exact d'une liste exhaustive de tous les symbôles qu'une plateforme applicative décide de gérer il n'est pas question ici d'octet de mémoire ou autre mais juste de symbôles.

En java la table des symboles utilisée est l'unicode. Unicode est aujourd'hui un standard de l'industrie.

L'encoding

L'encoding c'est ce qui fait le lien entre le symbôle et l'octet. Par exemple le symbôle "é" e accent aigu à pour valeur  en octet 

• En ISO-8859-1 :   -23
• En UTF-8 :            -61 -87
• En UTF-32 :          0 0 0 -23

Le é en unicode c'est à dire dans la table des symbole a pour valeur U00E9 en java voici le code que j'ai utilisé pour obtenir le résultat précédent : 

 public static void main(String[] args) {
  System.out.println(showBytes("\u00E9","ISO-8859-1"));
  System.out.println(showBytes("\u00E9","UTF-8"));
  System.out.println(showBytes("\u00E9","UTF-32"));
 }
 
 private static String showBytes(String str, String encoding){
  String result = "";
  try {
   for (byte b : str.getBytes(encoding)){
    result += " " + b;
   }
  } catch (UnsupportedEncodingException e) {
   e.printStackTrace();
  }
  return result;
 }

Les accidents

Supposons que j'écrive le "é" dans un fichier en utilisant l'encoding ASCII puis que je charge les byte du fichier dans un string en utiisant le mauvais encoding. Voici un exemple de ce que cela peut donner :

 On peut émuler toutes ces erreurs avec le code suivant

 
byte[] e_accent_aigu_en_ASCII = "\u00E9".getBytes("ASCII");
byte[] e_accent_aigu_en_ISO_8859_1 = "\u00E9".getBytes("ISO-8859-1");
byte[] e_accent_aigu_en_UTF_8 = "\u00E9".getBytes("UTF-8");
byte[] e_accent_aigu_en_UTF_32 = "\u00E9".getBytes("UTF-32");
  
System.out.println("ASCII byte, ASCII encoding = " + new String(e_accent_aigu_en_ASCII,"ASCII"));
System.out.println("ASCII byte, ISO-8859-1 encoding = " + new String(e_accent_aigu_en_ASCII,"ISO-8859-1"));
System.out.println("ASCII byte, UTF-8 encoding = " + new String(e_accent_aigu_en_ASCII,"UTF-8"));
System.out.println("ASCII byte, UTF-32 encoding = " + new String(e_accent_aigu_en_ASCII,"UTF-32"));
System.out.println("ISO-8859-1 byte, ASCII encoding = " + new String(e_accent_aigu_en_ISO_8859_1,"ASCII"));
System.out.println("ISO-8859-1 byte, ISO-8859-1 encoding = " + new String(e_accent_aigu_en_ISO_8859_1,"ISO-8859-1"));
System.out.println("ISO-8859-1 byte, UTF-8 encoding = " + new String(e_accent_aigu_en_ISO_8859_1,"UTF-8"));
System.out.println("ISO-8859-1 byte, UTF-32 encoding = " + new String(e_accent_aigu_en_ISO_8859_1,"UTF-32"));
System.out.println("UTF-8 byte, ASCII encoding = " + new String(e_accent_aigu_en_UTF_8,"ASCII"));
System.out.println("UTF-8 byte, ISO-8859-1 encoding = " + new String(e_accent_aigu_en_UTF_8,"ISO-8859-1"));
System.out.println("UTF-8 byte, UTF-8 encoding = " + new String(e_accent_aigu_en_UTF_8,"UTF-8"));
System.out.println("UTF-8 byte, UTF-32 encoding = " + new String(e_accent_aigu_en_UTF_8,"UTF-32"));
System.out.println("UTF-32 byte, ASCII encoding = " + new String(e_accent_aigu_en_UTF_32,"ASCII"));
System.out.println("UTF-32 byte, ISO-8859-1 encoding = " + new String(e_accent_aigu_en_UTF_32,"ISO-8859-1"));
System.out.println("UTF-32 byte, UTF-8 encoding = " + new String(e_accent_aigu_en_UTF_32,"UTF-8"));
System.out.println("UTF-32 byte, UTF-32 encoding = " + new String(e_accent_aigu_en_UTF_32,"UTF-32"));
  

Quelques points qu'il faut avoir en-tête

On voit que le "é" en ASCII n'existe pas, java l'a remplacé par le le byte du "?" en ASCII qui a pour valeur 63.

Quand java exécute String.equals,  String.contains ou String.match en interne il le fait symbole par symbole et non byte par byte comme peuvent le faire certains langage.

Enfin UTF-8 est un encodage qui peut être sur 1, 2, 3 ou 4 bytes ce qui signifie que les algorithmes qui vont interpréter les fichiers encodés en UTF-8 seront plus complexes à mettre en oeuvre que les algorithmes qui devront interpréter UTF-16 ou UTF-32 qui eux sont soit sur 2 ou 4 bytes pour chaque caractères. UTF-8 va partager le même encodage que ISO-8859-1 pour tous les caractères ascii ce qui permet en français de gérer des fichiers beaucoup plus légers car on ajoute des bytes en plus que pour les caractères non ascii.

Mais pour un texte entièrement en chinois ou en arabe UTF-32 permettra une interprétation plus rapide. Cela peut devenir très significatif pour un livre entier par exemple.

Comment gérer un dump mysql trop important

Je me suis retrouvé en production à devoir réinstaller un dump mysql très très lourd. Il faisait 22 Go.

Ce dump était très long a executer car il y avait des ordre d'insertion trop nombreux sur une table spécifique.

A chaque fois que je voulais ouvrir le fichier dans un éditeur de texte il plantait ou était inutilisable car la mémoire qui lui était alloué etait totalement pleine.

C'est ici qu'il faut sortir l'outil sed avec son option -i (inplace).

Bien entendu je recommande de faire un backup du fichier avant de se livrer à cette petite aventure.

 sed -i '/INSERT INTO `table_ou_il_y_a_trop_dinsertion`/c\-- removed' mondump.sql

La commande -i signifie inplace, le fichier sera changé directement sans passer par une copie intermédiare
le c\ signifie change, c'est donc toute la ligne ou cette expression a été trouvé qui sera changée.

Servlet Name doit être avant servlet class

En Créant un fichier web.xml j'ai eu une erreur étrange sur ce bout de code

<servlet>   
   <servlet-class>org.eclipse.jetty.proxy.ProxyServlet</servlet-class>
   <servlet-name>proxy</servlet-name>
</servlet>

Avec ce message

cvc-complex-type.2.4.a: Invalid content was found starting with element 'servlet-class'. One of 
 '{"http://java.sun.com/xml/ns/javaee":description, "http://java.sun.com/xml/ns/javaee":display-
 name, "http://java.sun.com/xml/ns/javaee":icon, "http://java.sun.com/xml/ns/javaee":servlet-
 name}' is expected.

En allant voir la xsd correspondantd à servlet, il est attendu que servlet name soit déclarer avant servlet class. Inverser les deux balises résout le problème.

<servlet>      
   <servlet-name>proxy</servlet-name>
   <servlet-class>org.eclipse.jetty.proxy.ProxyServlet</servlet-class>
</servlet>

Client Server Bluetooth en java : le code commenté.

1. Préparation
2. Un peu de théorie sur bluetooth
3. Le code commenté
4. Le projet eclipse avec toutes les dépendances

Voici maintenant le code commenté du client et du server.

Le code client

package bluetooth;

import java.io.DataOutputStream;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

import javax.bluetooth.DeviceClass;
import javax.bluetooth.DiscoveryAgent;
import javax.bluetooth.DiscoveryListener;
import javax.bluetooth.LocalDevice;
import javax.bluetooth.RemoteDevice;
import javax.bluetooth.ServiceRecord;
import javax.bluetooth.UUID;
import javax.microedition.io.Connector;
import javax.microedition.io.StreamConnection;

/**
 * Le code client.
 * 
 * Ce code est à executer sur l'ordinateur qui sert de client.
 * 
 * Ce code met en oeuvre les trois étapes que nous avons décrites précédemment : 
 * 1 On découvre les appareils autour de nous (inquiry)
 * 2 Recherche de service sur les appareils trouvés.
 * 3 Utilisation du service 
 * 
 * On remarque que l'api thread est mis en oeuvre ici car la méthode startInquiry 
 * démarre dans un nouveau thread (thread enfant) mais le thread père doit disposer d'un
 * moyen de savoir quand le thread enfant à fini. Pour faire cela on utilise la technique dite du 
 * sémaphore. Si vous ne la connaissez pas je vous conseille de commencer par lire ces quelques explications :
 *  
 * http://www.javaworld.com/javaqa/1999-11/02-qa-semaphore.html.
 * 
 *  
 */
public class Client {

 /**
  * La liste des devices bluetooth trouvés.
  */
 public static final List devicesDiscovered = new ArrayList();

 /**
  * Le service que je recherche sur ce device, un service doit avoir un nom unique, on utilise 
  * un utilitaire uuidgen pour générer ces chaines de caractère uniques.
  * 
  * Sur le code du serveur c'est aussi cette chaine qui est utilisés pour publier le service.
  *  
  */
 final static String myServiceUUID = "2d26618601fb47c28d9f10b8ec891363";
 
 /**
  * L'uid doit respecter certaine règle comme par exemple être positif la chaine doit faire 
  * moins de 32 caractère etc. La classe UUID contrôle ces règles lors de la construction.
  */
 final static UUID MYSERVICEUUID_UUID = new UUID(myServiceUUID, false);
 
 /**
  * La liste des services que l'on souhaite obtenir sur le devices. 
  */
 final static UUID[] searchUuidSet = new UUID[] { MYSERVICEUUID_UUID };
 
 /**
  * Lorsque l'on obtient le service, à la demande du client le serveur peut fournir 
  * des sortes de métadonnées (pair clé-valeur) appelés attributs. On pourrait imaginer un client 
  * qui voudrait envoyer de la musique à une chaine stéréro souhaiterai connaitre la liste des
  * formats musicaux supportés par le services. Sans spécificiation une liste d'attributs par défaut est fourni.
  * @see javax.bluetooth.DiscoveryAgent.searchServices(int[] attrSet, UUID[] uuidSet, RemoteDevice btDev, DiscoveryListener discListener)
  */
 final static int[] attrIDs = new int[] { 0x0100 }; // Service handle
 
 public static void main(String[] args) throws IOException,
   InterruptedException {

  
  //inquiryCompletedEvent est un semaphore 
  //qui bloquera le thread a l'appel de sa méthode wait 
  //et qui le poursuivra a l'appel de sa méthode notifyAll
  final Object inquiryCompletedEvent = new Object();
  
  //serviceSearchCompletedEvent est un semaphore 
  //qui bloquera le thread a l'appel de sa méthode wait 
  //et qui le poursuivra a l'appel de sa méthode notifyAll
  final Object serviceSearchCompletedEvent = new Object();

  // on vide la listes des périphériques bluetooth que l'on va trouver
  devicesDiscovered.clear();

  //le listener qui déclenchera les actions quand des devices et les services seront trouvés.
  DiscoveryListener listener = new MyDiscoveryListener(devicesDiscovered, inquiryCompletedEvent, serviceSearchCompletedEvent);
  
  
  //dabord on cherche les devices 
  synchronized (inquiryCompletedEvent) {
   // on passe le listener à la méthode start inquiry, cette appel 
   // revient tout de suite car il a lieu dans un autre thread.
   boolean started = LocalDevice.getLocalDevice().getDiscoveryAgent()
     //GIAC correspond au profil générique.
     .startInquiry(DiscoveryAgent.GIAC, listener);
   if (started) {
    System.out.println("wait for device inquiry to complete...");
    // wait met en attente le thread principal qui attend 
    // maintenant qu'un autre thread le notifie.
    inquiryCompletedEvent.wait();
    System.out.println(devicesDiscovered.size()
      + " device(s) found");    
   }
  }
  
    //une fois les devices trouvés on cherche les services sur ces devices
    for (RemoteDevice rm : devicesDiscovered){
   synchronized (serviceSearchCompletedEvent) {
    System.out.println("search services on " +  rm.getBluetoothAddress() + " " + rm.getFriendlyName(false));
             LocalDevice.getLocalDevice().getDiscoveryAgent().searchServices(attrIDs, searchUuidSet, rm, listener);
    serviceSearchCompletedEvent.wait();
    System.out.println("Fin de la recherche de services");
   }
  }
  
  
  
  
 }

}

/**
 * on cree un listener que l'on passera à la méthode startInquiry pour
 * mieux comprendre le pattern listener
 * http://rom.developpez.com/java-listeners/.
 * Ce listener sera notifié a
 * chaque fois qu'un device sera découvert. Notifié signifie en fait que
 * ses méthodes seront appelées à chaque fois que le système découvrira
 * un device. On va donc redéfinir les méthodes pour mettre en oeuvre
 * nos actions à chaque dévouverte.
 * 
 * Les méthodes deviceDiscovered et inquiryCompleted du listener s'applique lors de l'inquiry,
 * alors que les méthodes servicesDiscovered et serviceSearchCompleted s'applique 
 * lors de la recherche de service sur un device. Je pense qu'ils auraient du créer 
 * deux listeners car ces deux actions sont quand même différentes. 
 * 
 *
 */
class MyDiscoveryListener implements DiscoveryListener {
 
 private List devicesDiscovered;
 
 private Object inquiryCompletedEvent;
 
 private Object serviceSearchCompletedEvent;
 
 
 /**
  * 
  * @param devicesDiscovered la liste des devices trouvés.
  * @param inquiryCompletedEvent le semaphore pour la recherhe de device.
  * @param serviceSearchCompletedEvent le semaphore pour la recherche de service.
  */
 public MyDiscoveryListener(List devicesDiscovered, Object inquiryCompletedEvent, Object serviceSearchCompletedEvent){
  this.devicesDiscovered = devicesDiscovered;
  this.inquiryCompletedEvent = inquiryCompletedEvent;
  this.serviceSearchCompletedEvent = serviceSearchCompletedEvent;
 }

 /**
  * Méthode qui sera appelee à chaque fois qu'un device est decouvert.
  */
 public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod) {
  System.out.println("Device " + btDevice.getBluetoothAddress()
    + " found");
  // on alimente la liste des devices trouvés pour pouvoir
  // exploiter
  // cette information ultérieurement.
  devicesDiscovered.add(btDevice);
  try {
   System.out.println("     name "
     + btDevice.getFriendlyName(false));
   System.out.println("Blutooth Adress "  + btDevice.getBluetoothAddress());
  } catch (IOException cantGetDeviceName) {
   cantGetDeviceName.printStackTrace();
  }
 }

 /**
  * Méthode appelée quand le système estime avoir fini son travail
  * d'inquiry pour nous cela signifie que notre liste de device est
  * complète.
  */
 public void inquiryCompleted(int discType) {
  if (INQUIRY_COMPLETED==discType){
   System.out.println("Device Inquiry completed!");
   synchronized (inquiryCompletedEvent) {
    //on notifie cette objet pour permettre 
    //au thread principal de revenir de sa méthode wait.
    inquiryCompletedEvent.notifyAll();
   }
  }else if (INQUIRY_ERROR==discType){
   System.out.println("inquiry request failed to complete normally, but was not cancelled.");
  }else if (INQUIRY_TERMINATED==discType){
   System.out.println("device discovery has been canceled by the application and did not complete.");
  }
 }

 

 /**
  * Quand l'ensemble des services publiés que vous avez souhaité
  * retrouver sont découverts cette méthode est appelée.
  * 
  * A chaque service correspond un service record c'est pourquoi 
  * on reçoit un tableau, qui correspond au tableau de service que vous avez demandé 
  * lors de l'appel de  javax.bluetooth.DiscoveryAgent.searchServices(int[] attrSet, UUID[] uuidSet, RemoteDevice btDev, DiscoveryListener discListener)
  * 
  * Si sur le device serveur vous n'avez publié 
  * qu'un seul service vous  recevrez logiquement un tableau avec un seul élément.
  * 
  * Au sein de ces services record se trouve des serviceAttribute. 
  * Les attributs par défaut sont fourni mais il est possible de 
  * demander à recevoir d'autres attributs. 
  * 
  * @see javax.bluetooth.DiscoveryAgent.searchServices(int[] attrSet, UUID[] uuidSet, RemoteDevice btDev, DiscoveryListener discListener)
  * 
  */
 public void servicesDiscovered(int transID,
   ServiceRecord[] servRecords) {
      
  for (ServiceRecord sr : servRecords){
   System.out.println("Service trouvé " + sr.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false) );
   
   //je vais maintenant pouvoir parler au sevice !!!!
   System.out.println("Envoie du message en cours");
   //on récupère l'url du service 
   //on pourrait sauvegarder cette url 
   //pour un acces direct au service sans passer
   //par la phase d'Inquiry
         String connectionURL =  sr.getConnectionURL (
                 ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false);
         try {
             System.out.println(
                 "Connection a " + sr.getHostDevice().getFriendlyName(false) + 
                 ", " + connectionURL);
             StreamConnection streamConnection =  (StreamConnection) Connector.open (connectionURL);
             DataOutputStream dataout = 
                 streamConnection.openDataOutputStream();
             //maintenant j'envoie hello world au serveur.
             dataout.writeUTF("Hello World");
             System.out.println("Message envoye, fermeture du canal");
             streamConnection.close();
         } catch (IOException ioe) {
             System.out.println(
                 " exception & + ioe");
         }
  }
 }
 
 /*
  * Cette méthode sera appelée quand la recherche de service 
  * sera finie. Comme dans cette exemple on parle immédiatement 
  * au service dès qu'on le trouve. elle ne nous sera pas d'une 
  * grande utilité.
  *  
  * @see javax.bluetooth.DiscoveryListener#serviceSearchCompleted(int, int)
  */
 public void serviceSearchCompleted(int transID, int respCode) {
  System.out.println("Service search completed!");
  synchronized (serviceSearchCompletedEvent) {
   //on notifie cette objet pour permettre 
   //au thread principal de revenir de sa méthode wait.
   serviceSearchCompletedEvent.notifyAll();
  }
 }
}

Le code Serveur

package bluetooth;

import java.io.DataInputStream;
import java.io.IOException;

import javax.bluetooth.DiscoveryAgent;
import javax.bluetooth.LocalDevice;
import javax.bluetooth.RemoteDevice;
import javax.bluetooth.UUID;
import javax.microedition.io.Connector;
import javax.microedition.io.StreamConnection;
import javax.microedition.io.StreamConnectionNotifier;

/**
 * C'est un serveur bluetooth il ne fait que répéter dans la console 
 * le message qu'il a reçu.
 * 
 * Ce code est a executer sur l'ordinateur qui sert de serveur.
 * 
 * @author michael
 *
 */
public class Server {
 
 public static void main(String[] args) throws IOException {
  // le nom du service car l'uuid n'est pas très parlant ...
  final String myServiceName = "echoService";
  /**
   * Le service que je publie sur ce device, un service doit avoir un nom unique, on utilise 
   * un utilitaire uuidgen pour générer ces chaines de caractère uniques.
   * 
   * Sur le code du client c'est aussi cette chaine qui est utilisés pour obtenir le service.
   *  
   */
  final String myServiceUUID = "2d26618601fb47c28d9f10b8ec891363";
  UUID MYSERVICEUUID_UUID = new UUID(myServiceUUID, false);

  // Définit l'url du service.
  //localhost car on est le serveur 
  String connURL = "btspp://localhost:"+MYSERVICEUUID_UUID.toString()+";name="+myServiceName;
 
  //on se rend découvrable 
  LocalDevice.getLocalDevice().setDiscoverable(DiscoveryAgent.GIAC);
  
  System.out.println("Creation d'un service " + connURL);
  
  // On publie le service record dans le SRDB (Service record database)
  StreamConnectionNotifier scn = (StreamConnectionNotifier)  
                                           Connector.open(connURL);                   
 
  // On accepte la connexion d'un client, tant qu'aucun client 
  //ne frappe à la porte cette méthode bloque.
  StreamConnection sc = scn.acceptAndOpen();
  //on lit ce que le client nous envoie puis on l'écrit dans la console.
  DataInputStream dataIn = sc.openDataInputStream();
  String s = dataIn.readUTF();
  System.out.println("Echo > " + s);
  sc.close();
  scn.close();
 }
 
 

}

Client Server Bluetooth en java : un peu de théorie.

1. Préparation
2. Un peu de théorie sur bluetooth
3. Le code commenté
4. Le projet eclipse avec toutes les dépendances

Cette partie a pour but de voir le minimum necessaire sur la spécification bluetooth pour pouvoir comprendre les apis logiciels que nous mettons en oeuvre dans ce tutoriel. Ce résumé à ma sauce s'appuie sur :

• Wikipedia  http://fr.wikipedia.org/wiki/Bluetooth 
• Le site officiel de bluetooth  https://developer.bluetooth.org/TechnologyOverview/Pages/Technology-Overview.aspx    
• Sur le site d'Oracle, putting the core API to Work : http://www.oracle.com/technetwork/articles/javame/index-140411.html

Le dernier article est très complet et je vous conseille de l'approfondir pour étudier l'utilisation du JSR 82.

Le stack bleutooth 

Ce sont les couches logicielles qui nous interesse et ne parlerons pas des couches matérielles. 

L2CAP

L2CAP (Logical Link Control & Adaptation Protocol) fournit les services de multiplexage des protocoles de niveau supérieur et la segmentation et le réassemblage des paquets ainsi que le transport des informations de qualité de service. Les protocoles de haut niveau peuvent ainsi transmettre et recevoir des paquets jusqu'à 64 Ko. Elle autorise un contrôle de flux par canal de communication.

La couche L2CAP utilise des canaux logiques.

Dans le java bluetooth stack cette couche est représenté par l'interface L2CAPConnection. Comme elle respecte le CLDC Generic Connection Framework (http://www.oracle.com/technetwork/systems/index-155711.html) elle est accompagnée de L2CAPConnectionNotifier qui permet de créer des connections de type server. 

En pratique on ne travaillera pas directement avec L2CAPConnection mais plustôt avec l'interface StreamConnection et StreamConnectionServer qui respecte les mêmes contrats. En effet travailler L2CAPConnection nous oblige à limiter la taille de nos paquets et à gérer le réassemblage de paquets. Néanmoins voici un exemple d'utilisation de des interfaces.   

//coté client 
//.....
 L2CAPConnection conn = (L2CAPConnection) 
//on suppose que le server écoute sur le port 1003 on verra qu'en fait les services 
//sont découverts dynamiquement.
          Connector.open("btl2cap://0050CD00321B:1003;ReceiveMTU=512;TransmitMTU=512");
PrintStream out = new PrintStream(conn.openOutputStream());
//...

//coté serveur 
//.....
L2CAPConnectionNotifier service = (L2CAPConnectionNotifier) 
           Connector.open("btl2cap://localhost:0050CD00321B;ReceiveMTU=512;TransmitMTU=512");
L2CAPConnection conn = (L2CAPConnection) service.acceptAndOpen();
InputStream is = conn.openInputStream();

Comme nous le disions précédemment "Elle autorise un contrôle de flux par canal de communication" c'est pourquoi on trouve dans ces deux urls les parametres ReceiveMTU et TransmitMTU :

/**
 * ReceiveMTU
 * specifies the maximum payload size this connection can accept, and
 * TransmitMTU specifies the maximum payload size this connection can
 * send
*/

RFCOMM 

Il est exigé d'un stack bluetooth qu'au dessus de sa couche L2CAP un protocole série soit émulé : RFCOMM (Radio frequency communication).

Cette exigence connu aussi sous Serial Port Profile (SPP) existe car beaucoup de processus savent communiquer avec ce protocole plutôt qu'avec L2CAP.

Par exemple pour les tests sur un PC on peut utiliser Hyper Terminal pour voir les données arrivant sur le port émulé COM.

Je ne présente pas d'exemple d'utilisation avec RFCOMM car je pense que c'est la même chose que pour L2CAP. On trouve deux classes : BluetoothRFCommConnection et BluetoothRFCommConnectionNotifier qui implémentent respectivement StreamConnection et StreamConnectionNotifier que nous allons étudier plus en détail.

 Je n'ai néanmoins pas approfondi cette partie et toute remarque est bienvenue.

SDP 

Service Discovery protocole, qui permet de découvrir les autres devices à portée du client. Le code du précédent article présente ce processus et est déjà abondemment commenté.

TCS 

Telephony Control Protocol, est un protocole obsolète orienté donnée binaire, je n'ai pas cherché à l'étudier, si vous pouvez apporter plus de précision sur son rôle c'est avec plaisir que je lirai vos commentaires.

OBEX

 Obex est un protocole permettant l'échange d'objet, nous n'allons pas l'étudier dans ce tutoriel, mais vous trouverez deux exemples de codes : 

Client Obex : http://bluecove.org/apidocs/overview-summary.html#OBEXPutClient
Server Obex : http://bluecove.org/apidocs/overview-summary.html#OBEXPutServer

Les profils

Un profil correspond à une spécification fonctionnelle d'un usage particulier. Les profils peuvent également correspondre à différents types de périphériques.

Les profils ont pour but d'assurer une interopérabilité entre tous les appareils Bluetooth. Ils définissent : la manière d'implémenter un usage défini les protocoles spécifiques à utiliser les contraintes et les intervalles de valeurs de ces protocoles.

On a vu un de ces profils SPP (Serial Port Profile), lorsqu'un insdustriel souhaite obtenir la certification Bluetooth il doit valider une certaine quantités de ces profils.

La notion de client et de serveur.

Il faut bien différencier la notion de client et de serveur, un serveur publie un service et un client le consomme. Un device peut à la fois être client et serveur, aucun stack ne met de limite à être soit uniquement client soit uniquement serveur.

Voici un diagramme d'activité qui illustre ce que nos deux codes (code client et code serveur) vont faire.

Le code client.

Il va commencer par découvrir les devices bluetooth autour de lui : Un casque bluetooth, un téléphone, un autre ordinateur, etc.

C'est la phase d'inquiry, il va envoyer des ondes tout autour de lui pour dire qu'il cherche à découvrir les autres devices. Si les autres devices ont décidé de se rendre découvrable alors ils répondront à ce message d'inquiry pour dire qu'ils sont présents. Cela permet au client d'acquerir les adresses physiques des devices autour de lui et lui permet de les mettre dans son cache.

Enfin une fois qu'il aura découvert ces devices il va demander s'il existe un service spécifique sur le devices auquel il s'adresse. Si la réponse est positive alors la communication va avoir lieu.

Le code serveur

Il publie un service en ajoutant donc une entrée (Un service record) dans le SDB (Service Data Base) puis il se met en attente d'une requète entrante.

Et La sécurité et l'appairage des appareils ?

Cette partie n'est pas de la responsabilité des codes serveur ou client. C'est le statck sous-jacent qui doit s'occuper de l'appairage et de l'authentification des appareils entre eux.

Au mieux les codes peuvent exiger que l'échange n'ai lieu que si les appareils se sont authentifiés et/ou que l'échange soit cryptés, mais ce n'est pas eux qui  géreront cette partie.

Client Server Bluetooth en Java : préparation.

1. Préparation
2. Un peu de théorie sur bluetooth
3. Le code commenté
4. Le projet eclipse avec toutes les dépendances

Cette article suppose que vous débutez en Java et sur Bluetooth et s'adresse à ceux qui souhaite avoir un tutoriel qui explique comment mettre en oeuvre un serveur et un client qui permettront à deux PC d'échanger des données.


Le code complet du projet eclipse illustrant ce tutoriel peut-être téléchargé ici, toutes les librairies sont incluses.
https://www.dropbox.com/s/e5r74khzt75wvbq/bluetooth.zip

Première étape, comprendre et vérifier le bon fonctionnement du  stack java bluetooth

Un stack bluetooth est une pile d'interface matériels puis logiciels permettant au logiciels utilisateurs de communiquer avec un device bluetooth. Plus on est haut dans la pile, plus le niveau d'abstraction est élevé.

Par exemple L2CAP est assez bas niveau et ressemble à un échange entre deux sockets, Obex permet l'échange de fichier, le profil main libre permet d'envoyer un appel téléphonique dans l'autoradio...

Nous reviendrons en partie 2 du tutoriel pour expliquer ces différentes couches et ce que l'on peut faire avec.

Différents fabricants ou éditeurs de logiciels (souvent des éditeurs d'OS) propose leur stack, parmi ceux-ci on peut citer les plus connus :

• Broadcom (WIDCOMM)
• Winsock (Microsoft)
• BlueSoleil (IVT Corporation)
• OS X (Universal Mac)
• Linux BlueZ (D-Bus BlueZ API)
• Linux BlueZ (historic BlueZ API)

Le stack java bluetooth est l'ensemble des api que que la plateforme java va mettre à votre disposition pour pouvoir écrire des programmes qui utiliseront ce stack natif sans avoir à vous préocuper du stack véritablement installé sur votre machine. En clair il va déléguer les appels à la librairie native qui sera installée sur votre poste.

En java les api d'utilisation du stack bluetooth sont défini par la JSR 82 : http://www.jcp.org/en/jsr/detail?id=82. Cette JSR a été créé en 2000 et sa dernière mise à jour est de 2010.

En utilisant cette api les développeurs n'ont pas à se préocuper de la façon dont l'os et les matériels gère bluetooth, leur code est (théoriquement) immédiatement portable pourvu qu'au classpath soit ajouté une implémentation du stack pour l'environnement cible.

Sur la base de cette JSR plusieurs éditeurs ont proposé leurs implémentations dont certaines en licence open-source comme bluecove. Tous les éditeurs n'ont pas forcément choisi de supporter tous les os comme electric blue qui ne supporte que les stacks windows.

Un mot sur les emulateurs

Pour faire tourner les tests unitaires, pour développer sur des machines ne disposant pas de stack bluetooth, on peut remplacer le stack natif par un émulateur. Pour blue cove on peut utiliser http://bluecove.org/bluecove-emu/. Electric blue fournit aussi un émulateur : http://www.javabluetoothstack.com/bluesim.htm.


Commençons par découvrir les devices bluetooth autour de nous

Je vais utiliser bluecove pour la partie pc aussi bien sur debian que sur windows

Le code complet du projet eclipse illustrant ce tutoriel peut-être téléchargé ici, toutes les librairies sont incluses.
https://www.dropbox.com/s/e5r74khzt75wvbq/bluetooth.zip

Installation sous Debian x64

Le support pour x64 de blue cove est disponible depuis la version 2.1.1 vous trouverez les derniers snapshots ici.
http://snapshot.bluecove.org/distribution/download/
Le projet eclipse les inclut également vous n'avez pas besoin de les télécharger.

Ensuite il faudra vous assurer que le package libluetooth-dev est installé sur la debian
# apt-cache show libbluetooth-dev

Sinon vous devrez l'installer
# apt-get install libluetooth-dev

Par défaut bluecove ira chercher cette librairie dans /usr/lib/ créer donc un lien sybolique vers cette librairie dans ce répertoire

# ln -s /usr/lib/x86_64-linux-gnu/libbluetooth.so /usr/lib/libbluetooth.so

Installation sous Windows

Windows 7 et Windows 8 on été testé avec une version récente du JDK sur un ordinateur portable disposant du bluetooth et ont fonctionné sans efforts particuliers.

Attention néanmoins pour les tests sous windows 8 j'ai utilisé le portable de ma femme et j'ai acheté un dispositif bluetooth USB car son HP n'avait pas de bluetooth intégré. Dans l'emballage de l'USB était proposé par défaut les drivers de BlueSoleil qui sont très mal supportés par BlueCove. J'ai du les désinstaller puis replugger le dongle et laisser Windows 8 installer son propre stack : Winsock. Pour une listes des stacks supporté par blueCove : https://code.google.com/p/bluecove/wiki/stacks.

 Lancer l'application

Maintenant pour tester que le java stack bluetooth est opérationel faite run as java application sur la classe Client.

Vous pouvez constater que mon Samsung Galaxy S2 a été découvert. Pour ce faire il faut rendre le téléphone découvrable le temps que vous exécutiez ce test : en activant le bluetooth android vous proposera de le rendre découvrable pendant deux minutes.


On remarque aussi que dans l'environnement linux c'est le stack bluez qui est utilisé, dans un environnement windows c'est le stack winsock qui sera utilisé.

Cette première étape est necessaire c'est l'étape d'inquiry: découvrir les autres dispositifs bluetooth. Après avoir découvert les dispositifs il faut maintenant se connecter à ces derniers.


Liens utile :

La documentation offcielle d'android sur l'utilisation de bluetooth
http://developer.android.com/guide/topics/connectivity/bluetooth.html

Un tutoriel sur l'api bluetooth d'android.
http://homepages.ius.edu/RWISMAN/C490/html/Android-Bluetooth.htm


Un tutoriel sur l'utilisation de la JSR 82
http://homepages.ius.edu/RWISMAN/C490/html/JavaandBluetooth.htm

Sur le site d'Oracle : Putting the core API to work
http://www.oracle.com/technetwork/articles/javame/index-140411.html

Petit pense bête de commande linux

Voici un petit florilège de commande vraiment pratique lorsque l'on se retrouve en ligne de commande que j'ai repris du wiki de lutece.

permet de chercher dans l'historique de la ligne de commande. (Esc pour en sortir)

"Ctrl + r"

On peut avoir toutes les lignes avec

history | grep 'marecherche'


Tuer tous les processus Java :

killall java

Quels processus écoutent sur le port 8080 :

lsof -i :8080

Quels processus sont associés à tomcat :

ps aux | grep -i tomcat

Supprimer le processus 21456 :

kill -9 21456

Suivre ce qui se passe dans le fichier de log "catalina.out" :

tail -f logs/catalina.out

Programmer la sauvegarde automatique de la base Mysql dans le cron linux (contab -e)

* */2 * * * mysqldump -uroot -pmotdepasse mabase -rdump`date +%Y%m%d`.sql > sauvegarde.log

Suivre l'utilisation du serveur par les processus (les touches z et c permettent de changer le mode de visualisation) :

top

Autres :

pgrep -u$LOGINNAME mysqld
strace -p20687 -f -c -q

Commandes Linux utiles

Utilisateurs

Ajouter un utilisateur

$ sudo useradd -m nom_utilisateur -s /bin/bash

Ajouter un utilisateur sudoer

$ sudo useradd -m nom_utilisateur -s /bin/bash -G admin

Supprimer un utilisateur

$ sudo userdel nom_utilisateur

Puis supprimer le dossier de l'utilisateur qui est probablement dans /home

$ rm -rf /home/nom_utilisateur

Gestion des fichiers

Convertir une arborescence de noms de fichiers d'un encoding à un autre :

convmv -f iso-8859-15 -t UTF-8 -r --nosmart --notest .

Convertir une arborescence de contenus de fichiers d'un encoding à un autre :

$ find . -name *.html -type f | (while read file; do iconv -f UTF-8 -t ISO-8859-15 "$file" > "${file%.html}.htmlnew"; done) $ find . -name "*.htmlnew" -type f | (while read file; do mv $file `echo $file | sed 's/\(.*\.\)htmlnew/\1html/'` ; done

Synchroniser un dossier avec rsync

$ rsync -avz -e ssh username@xxx.xxx.xxx.xxx:/home/username/folder/backup_srcp/mountmd2/srcp_prod/* .

 Cette commande synchronise le dossier courant avec le dossier distant /home/username/folder/backup_srcp/mountmd2/srcp_prod/ sur la machine xxx.xxx.xxx.xxx

Faire une recherche récursive d'un texte sur l'ensemble des fichiers du répertoire

$ grep -Ri le_texte_a_rechercher *

Remplacer une chaîne de caractères récursivement dans un dossier :

$ find /some/dir -type f | xargs sed -i 's|chaine_a_trouver|chaine_a_remplacer|'

Avec du REGEX :

$ grep -rlE "^regexhere$" /some/dir | xargs sed -i 's|string1|string2|'

Infos mémoire et espace disque

infos io

iostat > iostat.txt

infos memoire

$ cat /proc/meminfo > meminfo.txt  $ vmstat > vmstat.txt

usage disque

$ df -h > df.txt

usage disque par dossier :

$ du -h

usage disque du dossier courant : du -sh * * vitesse du disque - pour celle-ci, remplacer sdxX par les disques réellement utilisés :

$ hdparm -tT /dev/sdxX > hd_sdxX.txt

activités systèmes

$ sar -A > sar.txt

info matériel

dmidecode > dmidecode.txt

Vérifier les ports d'écoutes :

$ netstat -l

Commandes VIM

Aller à la fin d'un fichier avec Vim :

MAJ + G

Aller au début d'un fichier avec Vim :

1 puis G

Aller à la ligne XXX d'un fichier avec Vim :

XXX puis G

MySQL

Lister les tables d'une base MySql :

mysql -uroot -pmotdepasse -Dlutece -e"show tables"

Sauvegarder une base de donnée du nom de "lutece" dans "dump.sql" :

mysqldump -uroot -pmotdepasse lutece -rdump.sql

Jouer le script "dump.sql" dans la base "lutece" :

mysql -uroot -pmotdepasse -Dlutece -e"source dump.sql"

Apache sur Ubuntu

Voir la liste des modules disponibles d'Apache :

$ ll /etc/apache2/mods-available

Ajouter un nouveau module Apache :
$ sudo a2enmod
$ sudo service apache2 restart 

Retirer un module Apache :
$ sudo a2dismod
$ sudo service apache2 restart 

Ajouter un site :

$ sudo a2ensite

$ sudo service apache2 restart

Installer virtual box sur la debian 7.1 Wheezy

Je rédige ce petit billet car j'ai eu quelques difficultés à installer virtualbox sur ma debian wheezy.

En passant par le gestionnaire de paquets j'ai récupéré ces messages d'erreurs au moment où j'ai voulu démarrer une VM XP

Virtualbox, Kernel driver not installed (rc=-1908) 

Après quelques lectures il s'avère necessaire d'installer virtualbox-ose-guest-dkms qui necessite lui-même les headers de linux.

Un lien pour mieux comprendre le rôle des DKMS.

On commence donc par installer les headers

 apt-get install linux-headers-$(uname -r)

Puis ensuite installer virtualbox en ajoutant le package virtualbox-ose-guest-dkms


apt-get install virtualbox virtualbox-dkms virtualbox-ose-guest-dkms virtualbox-guest-utils virtualbox-guest-additions virtualbox-qt

Ensuite plus de soucis virtual box fonctionne bien avec XP.

Learn multiplication tables with Space invader !

Type the alien value and press enter to kill it. Level Beginner Intermediate Confirmed Master more options below

Sorry, your browser is not supported. Update your browser : IE 9 or greater, Any versions of Chrome, Firefox 2 or greater, Opera 9 or greater. Updtating your browser improve also the security

Tables 1 2 3 4 5 6 7 8 9 10

What's the role of save and restore in canvas context

When I started to work with canvas I was wondering the role of save and restore in canvas.

 Save store the drawing state of the context, do interesting things with a new drawing state and restore it when you have finished.

 Let's take an example to understand it. Imagine you want to build an ellipse and a circle. For the circle no problem :

 

But there's no function for the ellipse except if you decide to change the scale of the drawing context.

 The drawing state of the canvas has been changed with ctx.scale(1,0.6) which flat the coordinate system on the y axis, creating an ellipse.

So why not creating a circle and an ellipse this way :

As you can see I made an ellipse and a circle but they don't have the same center because when I scale vertically the drawing state it reduced the coordinate of the y center. Beside I kind of restore the drawing state with this code ctx.scale(1, 1/0.6); which is error prone because you may forget a change you didn't undo.

Here is a solution with translate and save/restore

 Now we have an ellipse and a circle with the same center.

Comment fonctionne les transactions bitcoins pour les nuls.

Comprendre comment fonctionne le système de transactions des bitcoins n'est pas simple, on trouve bien ce schéma sur zerohedge qui a le mérite de faire une bonne synthèse mais ne s'adresse pas exactement à des "nuls". Je me propose donc de le faire ici, car je suis aussi un "nul".

Lorsque je parle de bitcoins avec mes amis l'idée d'une monnaie virtuelle ne plait pas beaucoup, parce que c'est virtuelle justement. J'ai souvent pas trop de mal à contrecarrer cet argument en expliquant que finalement une monnaie papier est tout aussi virtuelle, c'est une norme imposée par une banque centrale et qu'à tout moment on risque une très grosse inflation, si cette banque a envie de faire marcher son imprimerie.

Prenons l'or ou l'argent, bitcoins est beaucoup plus proche de ces valeurs d'échanges que ne pourrait l'être l'euro ou le dollar. Aucune banque ne peut émettre artificiellement de l'or. Si on veut mettre plus d'or sur le marché il faut le sortir des mines et de toute façon les ressources sont physiquement limités par les réserves naturelles de la planète, plus ça va plus obtenir de l'or devient dur.

Et bien bitcoins suit exactement cette règle. Il s'agit de séquences numériques obéissant à des propriétés mathématiques particulières qui font qu'elles sont  limitées en nombre (21 millions de séquences possibles) et plus ça va plus c'est difficile à trouver.

A ce stade vous me direz qu'à la différence de l'or le bitcoin n'est qu'une séquence numérique, je n'ai qu'à faire un copier coller. Avec de l'or ou de l'argent (ou avec sa copine) on ne peut pas faire de copier coller. Comment est-ce qu'on garantit que quelqu'un n'envoie pas deux fois le même bitcoins à des personnes différentes ?

Et bien c'est ici qu'intervient ce que l'on appelle le journal des transactions, à chaque fois que vous versez un bitcoins à quelqu'un vous le déclarez à tout le réseau et tous les nœuds l'enregistrent dans leur journal de transaction. Finalement le bénéficiaire du bitcoin recevra des confirmations des autres membres du réseau lui signifiant que cette transaction est valide.

Si par exemple le noeud 1 après avoir envoyé des bitcoins au noeud 2 tente d'envoyer maintenant les mêmes bitcoins au noeud 3 il pourra le faire mais cette transaction ne sera pas validée par les autres noeuds qui dans leur journal de transaction auront enregistré que les bitcoins sont bien en possessions du noeud 2 et ne peuvent donc plus être transférés depuis le noeud 1.

En fait si le noeud 3 a un journal de transaction à jour il pourra lui-même invalider ce transfert car il pourra y lire que le noeud 1 a déjà donné ces bitcoins au noeud 2.

Oui mais là vous pourriez m'opposer cet argument : qui détient la vérité ? Comme nous sommes sur un système décentralisé chacun maintient le journal des transaction. N'oublions pas que c'est le journal de toutes les transactions ! Tout les échanges qui ont pu avoir lieu depuis la création du bitcoin sont enregistrés dans ce journal.  Donc ça pèse assez lourd sur un PC ...

Dans cette capture vous constatez que mon journal fait bientôt 8 Go ...

Et puis encore une autre question : si le logiciel est hors ligne pendant trois mois, comment remet-il à jour son journal quand il revient en ligne.

Ici mon client bitcoins remet son journal des transactions à jour, il a 11 semaines de retards.

Et bien la réponse à ces deux questions (qui détient la vérité et comment un journal de transactions est-il mis à jour) est la même : c'est celui qui à la plus longue qui a raison !

Non non, ça n'est pas ce que vous croyez, quand je parle de la plus longue, je parle évidemment de la longueur du journal des transactions. Ce journal de transaction est plus connus sous le nom de chaîne de blocks. Donc celui qui a raison est celui qui a la chaîne de blocks la plus longue. Et quand un client doit se remettre à jour il recopie la chaîne de blocks la plus longue disponible sur le réseau.

A ce stade on peut se poser deux questions : pourquoi des chaines de blocks, et pourquoi la plus longue est-elle la gagnante ?

On parle de chaine blocks parce que les transactions ne sont pas ajoutées une à une au journal des transactions mais elles sont regroupées en blocks et sont ensuite intégrées au journal de transaction.

Mais ce processus d'intégration du block est un processus qui exige de la puissance processeurs et surtout qui peut être fait collectivement. Ainsi 10 processeurs répartis sur le réseau travaillant collectivement à l'intégration d'un block ira plus vite que 5 processeurs ayant les mêmes caractéristiques. Ce qui nous amène à ceci : s'il y a plus de gens honnêtes qui travaillent pour intégrer des blocks que de gens malhonnêtes alors la chaîne de blocks qui détient la vérité sera la plus longue ...

Pour ne pas aider ceux qui serait tenter de "réécrire l'histoire des transactions", l'intégration d'un block dépend toujours du block précédent.

Supposons que je sois un pirate qui décide de réécrire l'histoire des transactions et que je décide de changer une transaction située dans le bloc b3.

Je ne devrai pas seulement refaire l'intégration de b3 à la chaine mais aussi de b4, b5 et b6, ce qui va exiger du temps et de la ressource. Pendant ce temps les nœuds honnêtes continue d'ajouter des blocks, ils sont donc toujours en mesure de présenter une chaîne plus longue que celle je tente péniblement de réécrire.

En fait on montre que la probabilité qu'un pirate rattrape les blocks diminue exponentiellement a chaque bloc de retard. Et pendant que le bénéficiaire attend les validations de nouveaux blocks sont ajoutés.

Mais alors comment sont rémunérés ceux qui valident les blocks. Et bien vous pouvez accélérer les validations en intégrant des frais de transactions, le nœud qui aura intégré votre transaction dans la chaîne recevra ces frais.

Pour conclure on a un système qui est garanti par une information faisant autorité sans que cette information soit garantie par une autorité. C'est quelque chose de complètement nouveau qui n'a pas de précédent dans l'histoire.