Hi,

You can use pipes(unnamed) for communication between related processes i.e parent
and the child(s) process(es) on the same machine, not across processes running on 
different 
machines. Also with FIFOs, message queues, shared memory only the communication between
processes on the same host is possible. All these local IPC mechanisms require shared 
memory
and the unix kernel.

  The best option is to go for TCP/IP sockets. Depending upon your requirement you can 
use 
either STREAM ( connection oriented  and reliable ) or DATAGRAM ( connectionless and 
unreliable ) variations. This form of remote IPC will provde you various networking
APIs to exchange data between processes different machines.

For more details about unix network programming with C, please refer the book 
"UNIX Network Programming by W. Richard Stevens"

HTH,
-- 
Narsimha Reddy CH
Storage Area Networking, HCL Technologies
Contact  +91-044 2372 8366 ext 1128

http://san.hcltech.com
http://www.hcltech.com


Tom Sanders wrote:
> 
> I have two application servers running at different
> machines and I want to provide a function call type
> (synchronous) interface to applications.
> 
> This operation may mean one server to send/receive
> data from another server. Since I want application to
> be unaware of such inter-machine communication and
> yet provide a synchronous interface, I want client
> call to be blocked in local server unless all data is
> ready.
> 
> Any suggessions about good ways of achieving this
> functionality? Message Q, Pipes, anything? Your inputs
> will be appreciated.
> 
> Thanks,
> Tom
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> _______________________________________________
> Redhat-devel-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-devel-list



_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list

Reply via email to