Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Using channel at client and server side for bi-directional communication : (3 Items)
   
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
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
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