(WNPComm) Named pipe communication
silvano
I have written a small module to achieve a reliable communication
between two process using named pipes (or fifo). The name is WNPComm.
I have also written the Tcl bindings. Perhaps someone is interested to
try it, and perhaps someone would participate in its development.
WNPComm is a part of Linuxwoodo open-source project. This is mainly a
container for sub-projects. So, you can see more details on the
Linuxwoodo website:
http://linuxwoodo.sourceforge.net
WPCOMM WEBSITE SECTION
If you choose WPComm on the left-side menu then the right-side menu
will show you all the available options (download, documentation,...
and so on).
DOWNLOADING
In the download section you can find the source code (tar.gz), the
Slackware binary package (.tgz), and a self installing file (.sh).
DEPENDENCIES
In order to use WNComm you have to install wgClibs and wgCppLibs. They
are C and C++ generic libraries. You can find them on Linuxwoodo
website.
FUTURE
In the future I would add a network layer, and an asynchronous storage
layer. Over this I will write the Perl bindings too, and I
will try to write and fix the English documentation. I am sorry
because the English docs are uncompleted and with language errors
inside, but my English is far to be good :-(
For every question, please, write me an email: cati...@yahoo.com.
Thank you very much for your time, I will be happy to read feedback,
suggestions, comments... and to receive fix, path... I will be happy
to answer to everyone.
Silvano Catinella <cati...@yahoo.com> - Italy
Arjen Markus
>
> Thank you very much for your time, I will be happy to read feedback,
> suggestions, comments... and to receive fix, path... I will be happy
> to answer to everyone.
>
I have "wikified" it for you.
Regards,
Arjen
Alexandre Ferrieux
>
> Thank you very much for your time, I will be happy to read feedback,
> suggestions, comments... and to receive fix, path... I will be happy
> to answer to everyone.
>
Sorry but I don't get the whole thing: what problem does this solve
that more traditional IPC doesn't ?
-Alex
silvano
wrote:
> [...]
> Sorry but I don't get the whole thing: what problem does this solve
> that more traditional IPC doesn't ?
>
> -Alex
Ok, I was waiting this question. When you are using a fifo (or named
pipe) as communication channel between two processes you have the next
problems:
1) In C, if you read data with low-level functions (read/write) you
have to tell the system how many bytes you want, and if you ask too
many bytes then the number of read byte is returned.
So you have to manage possible temporary empty-buffer situation. With
high level languages you cannot use low-level functions, you have to
use functions using streams, and you have different type of problems.
You can send one char at the time, but it is terrible slow.
However, the first level of WNPComm protocol, manage the low-level
read/write operations.
2) BSD Fifo is unidirectional.
In the level 2 of my protocol, the fifo where the sender will wait the
answer is included into the package.
3) Unix fifo file does not manage the concurrent access.
The 3th level manage the file locking
4) Data loosing. If one process close the channel before the other has
completed read the bytes then you will loose data.
The level 3 synchronizes the channel closing procedure
In this sense WNPComm provides a reliable communication using fifo.
Over this I want add other useful features (eg. networking)
I hope my answer help you. However I will be happy to answer to every
question about my project. For further details please write me an
email: cati...@yahoo.com
Silvano Catinella
Alexandre Ferrieux
What would lead an app designer to use your package instead of plain
TCP sockets (possibly on the loopback interface) ?
They have none of these shortcomings...
-Alex
silvano
wrote:
> What would lead an app designer to use your package instead of plain
> TCP sockets (possibly on the loopback interface) ?
> They have none of these shortcomings...
>
> -Alex
Ok, It is not a good solution to use network-stack for local
communication, it is system resource waste. Although the modern
systems are very powerful the following points still a better
solution:
1) do not waste the system resources
2) lighter program means better program
3) more simple is better
But is is only my humble opinion
Silvano
silvano
Thank you so much, and sorry for my English, it is not so good.
Uwe Klein
> Ok, It is not a good solution to use network-stack for local
> communication, it is system resource waste. Although the modern
> systems are very powerful the following points still a better
> solution:
>
> 1) do not waste the system resources
network stacks have sucked up quite a bit of effort
towards resource efficiency over time.
> 2) lighter program means better program
imho using a socket is "lighter" than using an extra package.
> 3) more simple is better
should be as simple as possible, but not simpler (AE)
>
> But is is only my humble opinion
>
> Silvano
Don't write two different solutions for the same problem.
With IP sockets you have a universal interface that is
location and platform agnostic.
uwe
Donal K. Fellows
wrote:
> What would lead an app designer to use your package instead of plain
> TCP sockets (possibly on the loopback interface) ?
> They have none of these shortcomings...
Pipes are much simpler when you're only going to have (effectively)
one reader at a time. You don't need to fiddle around with listening
and determining whether the other end is the right entity to connect
or stuff like that.
Donal.
Alexandre Ferrieux
wrote:
Donal, I know that. And I know you know I know that :)
But I don't need a Brand New Layer Above Pipes. Especially not a
nonportable one.
-Alex
silvano
wrote:
Sorry, you do not need it, but other persons could find WNPComm
useful.
I have tried to explain that WNPComm is different by using a fifo
without a protocol. So, at the end, WNPComm gives a useful features.
About the portability, in the future I want compile the library core
for Solaris-Sparc and FreeBSD-x86. I agree with you: C is not a
portable language. But it is very powerful and fast. I appreciate Tcl
for its possibility to be interfaced with C.
Silvano
silvano
Sorry, but using network connects for processes that lives on the same
system does not look like a good solution IMHO. Sure, you can solve
two problems with the same solution, but it does not mean it is better
solution. Sure, it is more comfortable for who writes the code. But
you leave an unnecessary open network access. You probably will want
protect it, so you will need a firewall.
You could use Unix-socket but they are similar to the bsd named-pipe,
So you do not solve two problems with one solution.
If the universal solution would be the best then I should use Java
language. But Java wastes huge quantity of system resources.
My notebook is a Pentium-III 400Mhz, and I do not need to change my
hardware, because I do not use Java, or big "universal solutions". I
prefer to optimize my software.
Silvano