You may have been following the buzz around bad 2D performance of nvidia-drivers, specially with KDE 4. Well, I found out that QEdje was running slower than it could on my machine due to the same reason.

Zack Rusin released yesterday a nice benchmark utility for Qt, QGears2, which I used to measure the effect of Lemma’s suggestion on KDE’s techbase.

My machine is a 2.4GHz Core 2 Duo / 2gb / nVidiaGeForce 8600M 256mb MacBook Pro, running Gentoo ~x86.

The first tests were conducted using:

• Xorg-server 1.4.2
• Xorg 7.3
• nvidia proprietary drivers (nvidia-drivers) 173.14.12

The second test session were conducted after the following changes:

• nvidia proprietary drivers (nvidia-drivers) 177.67 beta (I’ve unmasked them in Gentoo)
• Added PixmapCacheSize and OnDemandVBlankInterrupts options to xorg.conf
• applied InitialPixmapPlacement and GlyphCache hacks:

  nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

GEARSFANCY results:

Old setup:

• -image  –>  42 fps
• -render –> 35 fps
• -gl –> 396 fps

New setup:

• -image  –>  67 fps
• -render  –>  41 fps
• -gl  –>  476 fps

Let me know of your results.

Cheers,

Fleury

Well, now I figured out that adding the “-u” flag to emerge restored the expected behaviour.

Maybe I was supposed to use “-u” since day one but the fact is I didn’t, and emerge worked fine until now. Anyway, if any of you face the same issue, try “-u”.

Cheers,

Fleury

I’ve been working on the QEdje project and, while studying possible optimizations, our team was interested in measuring whether we could benefit from using MIT’s X11 shared memory extensions. Among other tests, I managed to run x11perf on the N800.

A simple patch was needed before cross-compiling it. This because this app has a hard-coded window size of 600×600 pixels, more than what’s available in our 800×480 screen, thus leading to a X error message, complaining about get screen parameters.

I also reduced the square side size from 500 to 400 pixels in the XShmPutImage and XPutImage tests (shmput500 and putimage500).

The results were absolutely favorable to the use of the shared memory extension as you can see below:

./x11perf -shmput500 -sync

800 reps @ 8.6566 msec ( 116.0/sec)

./x11perf -putimage500 -sync

360 reps @ 14.8336 msec ( 67.4/sec)

For those willing to reproduce the tests, the patch is available below and should apply cleanly to x11perf 1.5.

Download x11perf 1.5 patch

Cheers,

Fleury

The bug sympthons are a very unresponsible system after leaving the screen locked for several hours, ie. all night, for instance, simply unlocking it was almost impossible. It was also possible to see intense flickering of the screensaver unlock dialog.

Logging to the terminal was possible though and I found out that there were many kdesktop_lock instances running (more than 80) and they were eating up all machine resources. Killing all of them (ie. pkill kdesktop_lock) would bring the system back to life.

To understand what was happening I left a tiny script logging the number of kdesktop_lock instances all night so I could check the results the other day. It was then interesting to find out that two instances were being spawned every 5 minutes. Note that my screensaver timeout is 5 minutes, and I use two screens on KDE.

Probable cause, maybe due to the existance of a second monitor, KDE is failing to tell the screensaver is already active and is spawning a couple more, one for each screen, everytime the screensaver timeout is due.

Unfortunately I’m currently unable to investigate this bug in deeper detail due to our current QEdje project but, meanwhile you can avoid it by disabling automatic screensaver and starting it manually when needed.

Eu, Eduardo Fleury, e Rodrigo Vivi, teremos o prazer de apresentar duas palestras na manhã do Domingo, dia 04 e agradecemos antecipadamente a presença de todos.

As palestras são independentes porém relacionadas, a primeira, Embarcando no Linux para sistemas embarcados (Rodrigo Vivi) ocorrerá as 09.00h de Domingo e cobrirá os conceitos fundamentais das plataformas móveis embarcadas baseadas em Linux, mais especificamente o Mamona e o Maemo.

Na seqüência, às 10.15h apresentarei a palestra Velejando com o Linux para sistemas embarcados na qual discutirei aspectos focados no desenvolvimento de aplicações para estas plataformas, incluindo questões como o ciclo de desenvolvimento e uma comparação entre linguagens de programação, partindo então para uma introdução à linguagem Python e suas principais características.

Links:

• Ensol 2.0 - http://www.ensol.org.br/2008/
• Embarcando no Linux para sistemas embarcados - http://www.ensol.org.br/2008/node/74
• Velejando com o Linux para sistemas embarcados - http://www.ensol.org.br/2008/node/73

A few days ago the Canola2 SDK was released allowing users to run Canola2 on their Linux desktops for plug-ins and themes development. In this post I’ll show how one can add plugins to the SDK.

What you need

When deploying plugins to Canola2 SDK one must observe three main steps:

1. Install plug-in code
2. Install plug-in theme extension (for some themes)
3. Rebuild plug-in database

Note that some plug-ins require extra interface widgets, for those the 2nd step must be completed, for the others it will be skipped.

SDK directory structure

In Canola2 SDK plug-ins code is located at:

canola/plugins/<plugin_name>/*

Note that the <plugin-name> folder may be zipped so you may also see plugins in the form:

canola/plugins/<plugin_name>.zip

The theme extensions for each plug-in however are in a different folder:

canola/THEMES/<theme_name>-<plugin_name>.edj

Example HOWTO - Installing Canola YouTube plug-in

Note that <SDK-base-dir> is the directory where you installed the Canola2 SDK, aka the directory you run Canola2 from.

1. Get Canola YouTube plug-in binaries from maemo repository:

$ mkdir /tmp/canola-youtube

$ cd /tmp/canola-youtube

$ wget http://repository.maemo.org/extras/pool/bora/free/c/canola-youtube-plugin/canola2-youtube-plugin_0.1.1-maemo1_all.deb

2. Extract contents (see notes if you don’t have dpkg-deb installed)

$ dpkg-deb -X canola2-youtube-plugin_0.1.1-maemo1_all.deb .

3. Copy plug-in code to the SDK dir

$ cp usr/share/canola/plugins/canola-tube.zip <SDK-base-dir>/plugins/

4. Copy plug-in theme extension to SDK dir

$ cp usr/share/canola/themes/*.edj <SDK-base-dir>/THEMES

5. Rebuild plug-in database

$ cd <SDK-base-dir>

$ ./run-canola –shell

$ bin/cnl-rescan-collections

$ exit

6. Run Canola2 SDK and test the new plugin

./run-canola -n

Notes:

- You can use “alien -t” and “tar xf” to extract the .deb contents if you don’t have dpkg-deb installed on your system.

- If you download the source code of a plug-in you will have to compile each theme extension using “edje_cc” that comes with your SDK installation. Just run “./run-canola –shell” to set-up the environment and you’ll have the compiler available. For more information regarding making your own plug-ins check the “Plug-ins development” section in the Canola2 SDK Development-README.

Additional Information

Checkout the #canola channel on the Freenode.net IRC servers.

Cheers,

Fleury

Since March 3rd, 2008 I live and work in Recife, PE, northeast of Brazil and work in the Canola project. You can now reach me at #canola @ freenode, look for “efleury”.

Right now I’m attending to the Bossa Conference on Open Source Software for Mobile Embedded Platforms ‘08 in Porto de Galinhas, PE. Watch for some photos soon.

More info at: http://www.bossaconference.indt.org/

Basically I had to get a confirmation from the user (y/n) - ie. read char from the standard input - and process it accordingly. However, rather than waiting for the use to press Return, I wanted to read the char as soon as typed. Besides that, I also wanted to have a timeout to unblock my program and assume a default answer after a given period of time.

In BASH that would be as simple as:

In C this is not straightforward because, by default, UNIX terminals are line-oriented rather than byte-oriented. What does that mean? That means that your C program will only be aware of what was typed after the user presses <Enter>. And we still have the timeout issue. So how to do it?

The Canonical Mode

In Unix systems, the aforementioned line-oriented mode is called “The Canonical Mode”. This means that whatever you type is kept in an editable buffer managed by the terminal until you believe what you typed is right and press <Enter>. This is why you can use backspace, auto-complete, arrow keys, etc… And this is why getchar() or read() will block until <Enter> is pressed. :-/

Termios functions

Changing this behavior is easy with the termios set of functions, namely tcgetattr() and tcsetattr(), the documentation of which is available in man format - see termios(3).

These functions read or write terminal settings from or to struct termios arguments, these arguments (as explained in the same man page) have five components being that four bit masks and one integer array, each of these defining a group of related settings. In this post I focus on the ICANON and a few other related flags, however you can always read about the others in the man page.

Example 1 (Download it!):

/*************************************************************************
 * Author: Eduardo M. Fleury - talkto (at) eduardofleury.com              *
 * Site  : http://eduardofleury.com                                      *
 * Desc. : Example 1 from post: http://blog.eduardofleury.com/?p=16      *
 *                                                                       *
 *************************************************************************
 *                                                                       *
 * This program is free software: you can redistribute it and/or modify  *
 * it under the terms of the GNU General Public License as published by  *
 * the Free Software Foundation, either version 3 of the License, or     *
 * (at your option) any later version.                                   *
 *                                                                       *
 * This program is distributed in the hope that it will be useful,       *
 * but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 * GNU General Public License for more details.                          *
 *                                                                       *
 * You should have received a copy of the GNU General Public License     *
 * along with this program.  If not, see <http://www.gnu.org/licenses/>. *
 *                                                                       *
 *************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>

#include <poll.h>
#include <termios.h>

int main() {

  int our_opt = 0;                   /* Our secret number */
  char user_opt = 0;                 /* User guess        */

  struct termios tios, orig_tios;    /* terminal settings */

  
  /* Seed random number gen */
  srandom(time(0));
  
  /* Get our number */
  our_opt = random() % 10;
  
  /**********************************************************************/
  /* Ok, that's what we're here for... Lets play with terminal settings */
  /**********************************************************************/

  /* Get current terminal settings */
  if (tcgetattr(0, &orig_tios)){
    printf("Error getting current terminal settings\n");
    return 3;
  }

  /* Copy that to "tios" and play with it */
  tios = orig_tios;
  
  /* We want to disable the canonical mode */
  tios.c_lflag &= ~ICANON;

  /* And make sure ECHO is enabled */
  tios.c_lflag |= ECHO;
  
  /* Apply our settings */
  if (tcsetattr(0, TCSANOW, &tios)){
    printf("Error applying terminal settings\n");
    return 3;
  }

  /* Check whether our settings were correctly applied */
  if (tcgetattr(0, &tios)){
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Error while asserting terminal settings\n");
    return 3;
  }

  if ((tios.c_lflag & ICANON) || !(tios.c_lflag & ECHO)) {
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Could not apply all terminal settings\n");
    return 3;
  }

  printf("Choose a number [0-9]: ");
  fflush(stdout);

  read(0, &user_opt, 1);
  user_opt -= 48;
  
  /* Restore terminal settings */
  tcsetattr(0, TCSANOW, &orig_tios);
  
  if (user_opt == our_opt){
    printf("\nCool, you just won a helluva car!\n");
    return 0;
  }
  
  printf("\nThe right answer is %d. Take a walk, alright?\n", our_opt);
  return 1;

}

The code above should be straightforward to follow, note that we:

1. Get the current terminal settings with tcgetattr()
2. Disable the ICANON flag (Canonical mode) and enable the ECHO flag.
3. Apply the modified termios struct using tcsetattr().
4. Get the current terminal settings again and check it against the desired ones. This is important to do because tcsetattr() will report success whenever at least one setting was successfully changed, so, to make sure all of them where changed, we must manually assert it.
5. Call read.
6. Restore settings.

This works fine, read() will unblock as soon as the first char is typed. However we don’t have a timeout yet.

Timeout

In C you can use poll(2) to implement the timeout, this works fine and is efficient. In this example I could set Poll to wait for an event of type POLLIN on the file descriptor STDIN_FILENO and also set a timeout value so it would block until something is available for reading or the time is up. After poll exits, its return code will let we know whether we had a timeout or success. This can be seen below.

Example 2 (Download it!)

/*************************************************************************
 * Author: Eduardo M. Fleury - talkto (at) eduardofleury.com             *
 * Site  : http://eduardofleury.com                                      *
 * Desc. : Example 2 from post: http://blog.eduardofleury.com/?p=16      *
 *                                                                       *
 *************************************************************************
 *                                                                       *
 * This program is free software: you can redistribute it and/or modify  *
 * it under the terms of the GNU General Public License as published by  *
 * the Free Software Foundation, either version 3 of the License, or     *
 * (at your option) any later version.                                   *
 *                                                                       *
 * This program is distributed in the hope that it will be useful,       *
 * but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 * GNU General Public License for more details.                          *
 *                                                                       *
 * You should have received a copy of the GNU General Public License     *
 * along with this program.  If not, see <http://www.gnu.org/licenses/>. *
 *                                                                       *
 *************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>

#include <poll.h>
#include <termios.h>

int main() {

  int our_opt = 0;                   /* Our secret number */
  char user_opt = 0;                 /* User guess        */

  struct pollfd pfd = {0,0,0};       /* poll() settings   */
  int pr;                            /* poll() result     */
  struct termios tios, orig_tios;    /* terminal settings */

  
  /* Seed random number gen */
  srandom(time(0));
  
  /* Get our number */
  our_opt = random() % 10;
  
  /* Get current terminal settings */
  if (tcgetattr(0, &orig_tios)){
    printf("Error getting current terminal settings\n");
    return 3;
  }

  /* Copy that to "tios" and play with it */
  tios = orig_tios;
  
  /* We want to disable the canonical mode */
  tios.c_lflag &= ~ICANON;

  /* And make sure ECHO is enabled */
  tios.c_lflag |= ECHO;
  
  /* Apply our settings */
  if (tcsetattr(0, TCSANOW, &tios)){
    printf("Error applying terminal settings\n");
    return 3;
  }

  /* Check whether our settings were correctly applied */
  if (tcgetattr(0, &tios)){
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Error while asserting terminal settings\n");
    return 3;
  }

  if ((tios.c_lflag & ICANON) || !(tios.c_lflag & ECHO)) {
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Could not apply all terminal settings\n");
    return 3;
  }

  
  printf("Choose a number [0-9]: ");
  fflush(stdout);

  /*************************************************************
   * This is new                                               *
   *************************************************************/

  /* Wait 5000 miliseconds for an POLLIN event on STDIN. */
  pfd.fd = STDIN_FILENO;
  pfd.events = POLLIN;
  pr = poll(&pfd, 1, 5000);

  if (pr > 0){
    /* We have got something to read */
    read(0, &user_opt, 1);
    user_opt -= 48;
  }
  else if (!pr) {
    /* We got a timeout */
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("\nSorry, time is up.\n");
    return 2;
  }
  else{
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("\nPoll() error.\n");
    return 3;
  }

  /*************************************************************/

  /* Restore terminal settings */
  tcsetattr(0, TCSANOW, &orig_tios);

  if (user_opt == our_opt){
    printf("\nCool, you just won a helluva car!\n");
    return 0;
  }
  
  printf("\nThe right answer is %d. Take a walk, alright?\n", our_opt);
  return 1;

}

Timeout using only read()

Ok, poll() is nice but this post is not about it; so why not to implement a timeout using only read() and termios functions?

When ICANON is enabled the terminal has no difficulties to determine when the text input is ready to be sent to our application, just wait for an <Enter>. This task becomes more complicated when ICANON is disabled though. Should the terminal wait for more than one char before sending the text? Should it wait for a timeout?

Instead of a single answer for these questions, Linux lets the programmer tune the terminal to the best of his convenience, and this is what the variables c_cc[VMIN] and c_cc[VTIME] are for.

In a nutshell, if VMIN > 0, it determines the number of received chars upon which read() calls will return immediately. If it’s Zero than read() will block until one char is available (more on that in 1 minute).

At the same time, if VTIME > 0, it determines a timeout (in deciseconds) after which read() calls will return even if VMIN chars haven’t been read yet; Zero means no timeout. Cool, isn’t it?

What about the difference between VMIN = 0 and VMIN = 1? The difference is that in the former case the timeout counter (if applicable) will be started as soon as read() is called, which means that read() will return without any chars read after the timeout period; in the latter case however, the timeout is only enabled after the first char is typed and is reset when a new char arrives. Actually my understanding is that in terms of behavior, VMIN = 0 and VTIME = 0 are the same as VMIN = 1 and VTIME = anything. If you see a difference, please let me know.

So, our code would become:

Example 3 (Download it!)

/*************************************************************************
 * Author: Eduardo M. Fleury - talkto (at) eduardofleury.com             *
 * Site  : http://eduardofleury.com                                      *
 * Desc. : Example 3 from post: http://blog.eduardofleury.com/?p=16      *
 *                                                                       *
 *************************************************************************
 *                                                                       *
 * This program is free software: you can redistribute it and/or modify  *
 * it under the terms of the GNU General Public License as published by  *
 * the Free Software Foundation, either version 3 of the License, or     *
 * (at your option) any later version.                                   *
 *                                                                       *
 * This program is distributed in the hope that it will be useful,       *
 * but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 * GNU General Public License for more details.                          *
 *                                                                       *
 * You should have received a copy of the GNU General Public License     *
 * along with this program.  If not, see <http://www.gnu.org/licenses/>. *
 *                                                                       *
 *************************************************************************/

#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#include <unistd.h>
#include <poll.h>
#include <termios.h>
#include <time.h>

#define VMIN_VALUE 0
#define VTIME_VALUE 50

int main() {

  int our_opt = 0;                 /* Our secret number    */
  char user_opt = 0;               /* User guess           */
  
  int bytes_read = 0;              /* Number of bytes read */

  struct termios tios, orig_tios;  /* terminal settings    */

  
  /* Seed random number gen */
  srandom(time(0));
  
  /* Get our number */
  our_opt = random() % 10;
  
  /**********************************************************************/
  /* Ok, that's what we're here for... Lets play with terminal settings */
  /**********************************************************************/

  /* Get current terminal settings */
  if (tcgetattr(0, &orig_tios)){
    printf("Error getting current terminal settings\n");
    return 3;
  }

  /* Copy that to "tios" and play with it */
  tios = orig_tios;
  
  /* We want to disable the canonical mode */
  tios.c_lflag &= ~ICANON;

  /* And make sure ECHO is enabled */
  tios.c_lflag |= ECHO;

  /* Set timeout */
  tios.c_cc[VMIN] = VMIN_VALUE;
  tios.c_cc[VTIME] = VTIME_VALUE;
  
  /* Apply our settings */
  if (tcsetattr(0, TCSANOW, &tios)){
    printf("Error applying terminal settings\n");
    return 3;
  }

  /* Check whether our settings were correctly applied */
  if (tcgetattr(0, &tios)){
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Error while asserting terminal settings\n");
    return 3;
  }

  if ( (tios.c_lflag & ICANON)         || !(tios.c_lflag & ECHO) ||
       (tios.c_cc[VMIN] != VMIN_VALUE) ||  (tios.c_cc[VTIME] != VTIME_VALUE) ) {
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("Could not apply all terminal settings\n");
    return 3;
  }

  
  printf("Choose a number [0-9]: ");
  fflush(stdout);

  bytes_read = read(0, &user_opt, 1);

  if (!bytes_read) {
    /* We got a timeout */
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("\nSorry, time is up.\n");
    return 2;
  }
  else if (bytes_read < 0){
    tcsetattr(0, TCSANOW, &orig_tios);
    printf("\nRead() error\n");
    return 3;
  }

  /* Restore terminal settings */
  tcsetattr(0, TCSANOW, &orig_tios);

  user_opt -= 48;

  if (user_opt == our_opt){
    printf("\nCool, you just won a helluva car!\n");
    return 0;
  }
  
  printf("\nThe right answer is %d. Take a walk, alright?\n", our_opt);
  return 1;

}

Note that we set c_cc[VMIN] = 0 so read() can unblock even if nothing was typed and finally we define the timeout period using c_cc[VTIME] to 50 deciseconds (5 seconds). Then we use the return value of read() to determine whether it had an error, timeout or success condition.

This approach requires the use of non-canonical mode so you cannot use this to set a timeout when the user is required to enter a full line and you want to let him edit it, case when you must use poll(). I hope this is interesting from the learning point of view though. It’s always nice to understand how and why things work.

All examples in this page are released under the terms of GPLv3 and can be redistributed and modified under its terms.

Comments are always welcome and encouraged.

Take care.

Fabi, bienvenue a le monde du blogs!!!

http://fabithome.blogspot.com

Previous knowledge

Before I start, let me share what I expect you to know before reading this article, and also some references in case you are not familiar with these terms yet.

• Processes - A process is an independent part of a computer program; they are composed of a sequence of instructions that run following a sequential path, a private memory space and context information. Unlike threads, different processes don’t share memory, so when two of them need to communicate, we need to use one of the so called “inter-process communication methods”. For more information about that I recommend the Wikipedia and the book Modern Operating Systems, by Andrew Tanenbaum.
• Sockets - In this context, sockets are bi-directional inter-process communication channels; being available in several flavors, some of them allow communication through network interfaces, others rely on the system kernel only as the carrier, and so forth. Differences also exist on reliability, message boundaries preservation, etc. In this article I’ll focus on sockets of the family AF_UNIX (or AF_LOCAL), although most of the information provided here applies to all AF_UNIX sockets, examples will be based on sockets of the subtype SOCK_STREAM.

AF_UNIX sockets

These sockets provide a communication channel between two processes in the same machine, they are not visible from other machines and cannot be used to establish communication using the network interface. For the latter case see AF_INET sockets.

Every socket family has its own addressing scheme, while you can identify a specific AF_INET socket by an IP address/port pair, this is not true with AF_UNIX sockets. So, how do I address these? Please keep reading, this is what this post is all about.

Reliability is present in most AF_UNIX sockets implementations, the Linux implementation is an example. However, the only subtypes that are formally reliable are the SOCK_STREAM and SOCK_SEQPACKET types, both connection oriented but with some differences in the maximum message length and message boundaries preservation.

The challenge

A couple of weeks ago I was dealing with a situation where I had to code a script that would be run from a chroot’ed environment and that would be able to pull files from outside the chroot sandbox. In other situations I could do the opposite, ie. push files from the outside environment to the chroot folder, or maybe I could mount the source directory inside the chroot folder… but this case was different, neither I had control over the chroot’ing procedure nor I knew beforehand in which folder would my script would be running on. This because this script would be run in Anaconda’s or Yast’s post install, inside a just partitioned and installed system.

Although I could try using some heuristics to parse log files and discover the right target directory I wanted to make it right, put together something reliable, that I wouldn’t have to revisit in the future.

The idea

For some time I would think about how to do it… finally I though about some kind of client/server architecture where I would have a server with access to the files and a client run from the chroot’ed environment; both processes should communicate and the files would make their way through a pipe… or a socket!

Then I started some investigation on how to code my new idea, first I though of pipes, but these wouldn’t work as the processes would be started independently, from different shells, in different moments, and pipes need to be created at once, not in parts. Then I remembered sockets, AF_UNIX sockets.

Sockets create/bind/listen/accept logic

Before you can use sockets as a bi-directional communication channel, some handshaking and setup is necessary. Sockets of type SOCK_STREAM or other connection-oriented types follow the following logic until a connection is established:

1. Node A creates a new socket.
2. If node A wants its socket to be visible from other processes, it must publish it, or assign it to an univocal address. This assignment is called “binding“.
3. After the socket is bond to a name, node A must put its socket in the listen state, this creates a backlog queue where new connection requests will be placed and served on a FIFO base. If the socket is not in the listen state or if its backlog is full, connection attempts will be denied.
4. Finally, when node A has a bond socket and a connection request, all it needs to do is accept this request. The accept command can be blocking and this will make the server wait for a client before proceeding. After a successfully connection a new “connected socket” that can be used for communication is created.

In the client side the process is even more straightforward.

1. Node B creates a new socket, of the same family and type as the one Node A has created.
2. Node B tries to connect to an address it must know somehow. When the connection is established, communication occurs under the scheme defined by the socket type, for instance, as a reliable byte stream when you have a SOCK_STREAM socket.

This procedure is common for most sockets families and types, with just two exceptions: datagram oriented sockets don’t require connection (so it’s just create, bind and go) and, the address scheme. All sockets have to be bond to an address before connections are received, but addresses are different for each socket family.

For instance, when one is creating a socket to communicate with another computer in the network, it must bind to a given port and network interface. This pair, IP and port is the address the other node will need to use when connecting to that socket. In AF_UNIX sockets, the address is slight different as you will see below.

AF_UNIX sockets addressing

In most cases AF_UNIX sockets are bond to filenames, that’s the ordinary addressing space used by them. So the server creates a socket, binds it to a filename somewhere in its filesystem and waits for a connection. It was clear that wouldn’t solve my problem. If I had a folder where one of my processes could write and the other read my very first problem wouldn’t exist .

That’s when I found the Abstract Namespace.

The solution - Abstract Namespace

The Linux kernel holds in its memory space a table of open sockets. AF_UNIX sockets can be bond to “names” rather than “files”, it’s that simple, you just give your socket a name, an identifier, and then all other process can find it by its name, no matter which filesystem it’s running in! No matter whether it’s running in a chroot’ed environment or not!

In a few minutes I had a functional proof of concept, two processes talking, one inside a chroot’ed environment and the other outside. After that all I had to do was code some extra logic and avoid race conditions.

How to bind a socket to the Abstract Namespace

AF_UNIX socket names are always a sequence of chars, something like a C string, but with some peculiarities and differences in behavior. Instructing the bind function to use a filename or an abstract name is just a matter of crafting the right char sequence.

Ordinary bind names, that are associated to filenames, are simply ordinary strings, sequences of letters and numbers terminated by a null-byte. Calling bind with a “name” in this format will create a file in the path specified by “name”.

The trick to trigger the abstract namespace is simple: start the name with a null-byte. All characters found after the null-byte will then be interpreted as the identifier name and the socket will registered by the Kernel under the given name.

After that, just use the same string in the client and you will have a working socket.

Note for C programmers

Unlike high-level bind functions found in languages like Python, the bind(2) syscall arguments requires some attention. As you may have noticed in the above text, unlike C strings and path names, abstract namespace identifiers are not null-terminated strings; their length must be provided in the socklen_t addrlen argument. This means that the char sequences:

1. 0×48454C4C4F00 (”HELLO\0″) and
2. 0×48454C4C4F0000 (”HELLO\0\0″)

represent different bind points. So make sure you pass the right length to avoid segmentation faults or undesired behavior, especially when creating clients and servers using different languages.

Simple example in Python

BTW, sorry for the bad indentation, I still must find a nice way of posting code using this blog theme. Suggestions are appreciated Meanwhile, you can download the code here –> AF_UNIX - Python example.

Server code from socket import *

# Create an unbound and not-connected socket.
sock = socket(AF_UNIX, SOCK_STREAM)

# Bind the socket to “MyBindName” in the abstract namespace. Note the null-byte.
sock.bind(”\0MyBindName”)

# Create a backlog queue for up to 1 connection.
sock.listen(1)

# Blocks until a connection arrives. A tuple (connected_socket, None) is returned
# upon connection. Note we get the first argument and throw away the rest.
conn = sock.accept()[0]

# Say hi
conn.send(”Hello World\n”)

# Wait for response
msg = conn.recv(100)
print msg

# Close it, this will unblock the other peer in case it’s waiting for another message.
conn.close()

Client code

from socket import *

# Create an unbound and not-connected socket.
sock = socket(AF_UNIX, SOCK_STREAM)

# Connect to the peer registered as “MyBindName” in the abstract namespace. Note the ‘\0′.
sock.connect(”\0MyBindName”)

# Wait for message
msg = sock.recv(100)
print msg

# Send reply
sock.send(”Hi there!\n”)

# Block until new message arrives
msg = sock.recv(100)

# When the socket is closed cleanly, recv unblocks and returns “”
if not msg:
print “It seems the other side has closed its connection”

# Close it
sock.close()

That’s all for today. Don’t forget to leave your comment!