+ This module exports any of its functions only on request.
+
+PROTOCOL
+ Each byte of the data string is converted into its bits sequence, with
+ bits of highest weight coming first. All those bits sequences are put
+ into the same order as the characters occur in the string.
+
+ The header is composed by the "utf8" bit (if the data has to be decoded
+ to UTF-8), the "sign" bit (if sender gives its PID in the header), and
+ then 24 bits representing the sender's PID (with highest weight coming
+ first) if the "sign" bit is set.
+
+ The emitter computes then the longuest sequence of successives 0 (say,
+ m) and 1 (n) in the concatenation of the header and the data. A
+ signature is then chosen :
+
+ - If m > n, we take n+1 times 1 follewed by one 0 ;
+ - Otherwise, we take m+1 times 0 follewed by one 1.
+
+ The signal is then formed by concatenating the signature, the header,
+ the data bits and the reversed signature (i.e. the bits of the signature
+ in the reverse order).
+
+ a ... a b | u s [ p23 ... p0 ] | ... data ... | b a ... a
+ signature | header | data | reversed signature
+
+ The receiver knows that the signature has been sent when it has catched
+ at least one 0 and one 1. The signal is completely transferred when it
+ has received for the first time the whole reversed signature.
+
+CAVEATS
+ This type of IPC is highly unreliable. Send little data at slow speed if
+ you want it to reach its goal.
+
+ "SIGUSR{1,2}" seem to interrupt sleep, so it's not a good idea to
+ transfer data to a sleeping process.