TeamForge : Post

Forum Topic - Using channel at client and server side for bi-directional communication : (3 Items)

View: as

Haridas Puthiyapurayil

02/11/2012 1:55 AM

post91499

Using channel at client and server side for bi-directional communication

Hi,

I'm trying to use QNX IPC calls (MSgSend/MsgReply) mechnism to have bi-directional communication between two processes. 
Basically using channel at the both processes. I heard there could be a issue with this design and trying to understand 
more details on this design? Looks like QNX recommends using send hierarchy and non-blocking pulse.

Please help me to identify the issues with the first design as described in the begining of this message? 

Thanks
Hari

Sean Boudreau(deleted)

02/12/2012 10:28 AM

post91505

Re: Using channel at client and server side for bi-directional communication

The classic thing to look out for is having both servers SEND blocked on each other (deadlock).

You can keep one end the server and have it pass data back in the Reply rather than the Send (eg write() vs read()).

Regards,

-seanb

----- Original Message -----
From: Haridas Puthiyapurayil [mailto:community-noreply@qnx.com]
Sent: Saturday, February 11, 2012 01:55 AM
To: general-networking <post91499@community.qnx.com>
Subject: Using channel at client and server side for bi-directional communication 

Hi,

I'm trying to use QNX IPC calls (MSgSend/MsgReply) mechnism to have bi-directional communication between two processes. 
Basically using channel at the both processes. I heard there could be a issue with this design and trying to understand 
more details on this design? Looks like QNX recommends using send hierarchy and non-blocking pulse.

Please help me to identify the issues with the first design as described in the begining of this message? 

Thanks
Hari



_______________________________________________

General
http://community.qnx.com/sf/go/post91499

Haridas Puthiyapurayil

02/12/2012 8:05 PM

post91506

Re: Using channel at client and server side for bi-directional communication

Sean, thanks for your quick response. 

I was wondering if we keep more than one thread (on sender and receiver process), for each of the connector-channel pair
? any thoughts on having this model?


-Hari

Return