[Olsr-dev] nameservice plugin for Windows with olsr 0.5.6

[Bernd Petrovitsch]

On Mon, 2008-10-20 at 15:58 +0200, Olivier Brousse wrote:
> Bernd Petrovitsch a écrit : 
> > On Tue, 2008-09-09 at 18:37 +0200, Olivier Brousse wrote:
[...]  
> > > Can you provide me more informations on this writing files procedure? 
> > > What is the code in nameservice.c that is referenced here?    
> > 
> > Personally I don't know.
> > 
> > >From the code there: Just write to a new (temporary) file (on the same
> > filesystem), close it and rename it (to guarantee atomicity) to the
> > "fifoname".
> > The "fifo reader" checks periodically if the file changed (the inode
> > number changes because create a new file every time) and if yes, opens
> > and handles it.
[....]  
> Thank you for your answer but I'm afraid my poor C skills are not
> enough to understand what you tried to explain me. This may also comes
> from  the fact I don't know how work AFAIK FIFO.

IMHO more the latter. So a short mini-intro:
A FIFO (First-In-First-Out) is basically as pipe (based on the sys-call
with the same name) with a name in the filesystem. You can create one
with "mkfifo".

In the classical simple setup[0], you have (exactly) one reader and one
writer.
When the first of them open(2)s the fifo, it is blocked until the second
opens it. Both continue and block if the fifo is full or empty. The fifo
a (small) buffer so there is some kind of parallelism possible.
If the writer closes the file-descriptor, the reader gets EOF and also
closes the pipe.
And the game can start from the begin.

One usually uses a fifo to connect to otherwise in independent apps
similar to usual client-server approach (but a you can have one one
client as there is no accept(2) or similar).

For the reader/writer from above, a pipe behaves (to a certain extent)
like a plain file. You open(2) it, you read(2)/write(2) it and you
close(2) it at the end.
So if you can't use fifos for whatever reason, one could simulate it
with plain files: You just need two filenames (on the same filesystem).
- The writer open(2)s a file, write(2)s and close(2)s it (like with a
  fifo).
- But then the writer rename(2)s the file to the second name.
- The reader open(2)s, read(2)s and close(2)s it (like with a
  fifo).
- The reader may unlink(2)s it (to save space space).
How does the reader detects a new file?
- stat(2) the (new) file and compare the creation time with the one from
the last read file.
What happens if the writer rename(2)s the file while the reader read(2)s
it?
- Nothing. The reader continues to read the open(2)ed old file until he
close(2)s it.
Can I loose files?
- Of course. If the writer rename(2)s a new file before the reader
opened it, the old one is gone forever.
Can't I avoid that?
- Yes, make the reader much faster and the chances will drop.
- Or use more than one destination filename (usually numbered for the
correct sequence) and have the reader open(2) the next one.

The above doesn't work as a general replacement as the behaviour in time
(and some other subtle things) is different to the fifo version. So the
plugin author(s) should be able to tell - all others must dive deep into
the code to see if that works.

A better (and more flexible) alternative is IMHO to replace the fifo
with sockets or SysV-message queues. Or shared memory with the
appropriate (and necessary) synchronization.
The above quiet primitive "file queue" is more a workaround than a
solution.

Of course one can also use the fopen(3)/fgets(3)/fclose(3)/.... etc.
family of functions for all of the above.

Disclaimer: The above assumes POSIX-like semantics and behaviour.

	Bernd

[0]: With any "non-blocking" anywhere.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services