Communication between 2 processes by using signals

[ajay]

How 2 independent processes can communicate ( say to passing some
chunk of data) with "signals". Is it possible ?
Are signals is counted in IPC (Inter Process Communication).

Tx and regds
Ajay Singh

[Jens.Toerring@physik.fu-berlin.de]

ajay <ajay_kumarsingh@yahoo.com> wrote:

> How 2 independent processes can communicate ( say to passing some
> chunk of data) with "signals". Is it possible ?
> Are signals is counted in IPC (Inter Process Communication).

If you really need to you probably can, you can also implement TCP/IP
via carrier pigeons. You could e.g. code a binary 0 by sending SIGUSR1
and 1 with SIGUSR2. But that's probably going to be slow and you better
acknowlege each signal by resending it back to the originator to make
the data transfer reliable (i.e. to keep the originator from sending
the next signal before the previous one has been received). Probably
not a good idea when there are real IPC methods (and, no, signals
usually aren't counted as IPC, at least they aren't treated in the
second volume of Unix Network Programming by W. R. Stevens, where
he deals with IPC).
Regards, Jens
--
_ _____ _____
| ||_ _||_ _| [email]Jens.Toerring@physik.fu-berlin.de[/email]
_ | | | | | |
| |_| | | | | | [url]http://www.physik.fu-berlin.de/~toerring[/url]
\___/ens|_|homs|_|oerring

[Valentin Nechayev]

>>> [email]Jens.Toerring@physik.fu-berlin.de[/email] wrote:

>> How 2 independent processes can communicate ( say to passing some
>> chunk of data) with "signals". Is it possible ?
>> Are signals is counted in IPC (Inter Process Communication).

> If you really need to you probably can, you can also implement TCP/IP
> via carrier pigeons. You could e.g. code a binary 0 by sending SIGUSR1
> and 1 with SIGUSR2. But that's probably going to be slow and you better
> acknowlege each signal by resending it back to the originator to make
> the data transfer reliable (i.e. to keep the originator from sending
> the next signal before the previous one has been received).

Resending any signal back isn't good idea. Better one is to send packets
of data using such strange level for sending one bit. Packet should be
organized as in protocols for talking over unreliable serial lines, this
includes UUCP (g,i,G), ZModem, Hydra, PPP, and some others.
Of course, channel organized in this way will be too slow and expensive,
and the only reasonable application for it I see is saying name of local
socket or named pipe which will be used in following talk.

> Probably
> not a good idea when there are real IPC methods (and, no, signals
> usually aren't counted as IPC, at least they aren't treated in the
> second volume of Unix Network Programming by W. R. Stevens, where
> he deals with IPC).

Really, the whole bunch of current IPC methods is designed for efficient
interaction when contact addresses (TCP port, local socket...) is already
known for both sides. But this isn't enough for some cases.


-netch-