Server to client message problems

bridged with qdn.public.qnxrtp.porting
Post Reply
Brett Wilton

Server to client message problems

Post by Brett Wilton » Tue May 20, 2003 2:29 am

I use name_attach() in the server and MsgReceive() from mulitiple clients.
The clients connect to the server using the name_open() function. I can send
messages from the clients with MsgSend() and replies from the server with
MsgReply().

My question is, can the server send messages to the clients. I've tried
MsgSendPulse() and MsgSend() with no luck ? What coid values should I be
using, thats if this will work ?

Now I have managed to get a pulse sent to the client via the
MsgDeliverEvent() which in turn can cause the client to send and then
receive a reply. This does work. Is this the only way of doing this type of
message passing ?

I have not setup the code as a resource manager its more like the QNX 4 type
message passing setup at the present time.

Also as far as the QNX docs go under the MsgDeliverEvent() function there is
a client / server example that does work, however I think the server should
do a MsgReply() to the client before it sends the pulse event, as the
MsgSend() function is expecting a reply. The reason it works at the present
time is due to the server exiting, a while loop around the MsgReceive() and
MsgReceivePulse() soon shows the client is in the REPLY blocked state.

Any help here on the server / client arrangement is greatly appreciated,
Brett.

Xiaodan Tang

Re: Server to client message problems

Post by Xiaodan Tang » Tue May 20, 2003 2:46 am

Brett Wilton <bdwilton@xtra.co.nz> wrote in message
news:bac2mq$pf0$1@inn.qnx.com...
I use name_attach() in the server and MsgReceive() from mulitiple clients.
The clients connect to the server using the name_open() function. I can
send
messages from the clients with MsgSend() and replies from the server with
MsgReply().

My question is, can the server send messages to the clients. I've tried
MsgSendPulse() and MsgSend() with no luck ? What coid values should I be
using, thats if this will work ?
Unlike QNX4 proxy, to be able to send pulse, a connection needs to be
established. So if you want to send a pulse from server to client, the
client have to setup a channel first, and the server needs to connect to it
first.
Now I have managed to get a pulse sent to the client via the
MsgDeliverEvent() which in turn can cause the client to send and then
receive a reply. This does work. Is this the only way of doing this type
of
message passing ?
This IS the proper way. Bi-direction message passing will causing dead
lock very easy. Since QNX6 support threads, you can multi-thread your
server & client, and do bi-direction message passing. But again, you
have to be very clean of your code path, other wise, you are still
possiable dead locked.
I have not setup the code as a resource manager its more like the QNX 4
type
message passing setup at the present time.

Also as far as the QNX docs go under the MsgDeliverEvent() function there
is
a client / server example that does work, however I think the server
should
do a MsgReply() to the client before it sends the pulse event, as the
MsgSend() function is expecting a reply. The reason it works at the
present
time is due to the server exiting, a while loop around the MsgReceive()
and
MsgReceivePulse() soon shows the client is in the REPLY blocked state.
That is correct. The sample works, but didn't really show the logic. But I
believe our doc people is aware of that and will fix it in next release.

-xtang

David Gibbs

Re: Server to client message problems

Post by David Gibbs » Tue May 20, 2003 3:38 pm

Brett Wilton <bdwilton@xtra.co.nz> wrote:
I use name_attach() in the server and MsgReceive() from mulitiple clients.
The clients connect to the server using the name_open() function. I can send
messages from the clients with MsgSend() and replies from the server with
MsgReply().

Now I have managed to get a pulse sent to the client via the
MsgDeliverEvent() which in turn can cause the client to send and then
receive a reply. This does work. Is this the only way of doing this type of
message passing ?
This is the recommended way of going. It is the equivalent of the
QNX4 example:

client: qnx_proxy_attach(), Send() message with proxy id in it.

server: Receive() message, store away proxy id, Reply().

later:

server: Trigger() proxy;
client: Receive() proxy, Send() to server, get Reply() with data from server.
Also as far as the QNX docs go under the MsgDeliverEvent() function there is
a client / server example that does work, however I think the server should
do a MsgReply() to the client before it sends the pulse event, as the
MsgSend() function is expecting a reply. The reason it works at the present
time is due to the server exiting, a while loop around the MsgReceive() and
MsgReceivePulse() soon shows the client is in the REPLY blocked state.
Yeah, the example needs updating. The server should REPLY.

In fact, the server should also store away scoid and rcvid for the
client, and then when it gets/handles the disconnect pulse, look up
that scoid, and remove that client's rcvid from its list of people that
it could MsgDeliverEvent() to.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.qnxrtp.porting”