The Server creates the Channel, and the client connects to it.
If you are not using resource manager then you can use the name_attach() and
name_open() calls to create and connect to the channel.
There is sample client/server code in name_attach() library reference doc.
I just look at the MsgDeliverEvent() function and there was an example
in which client created a channel to get pulse, but server also has a
name registered. So client sned to server and receives pulse on his own
created channel. How is that?
I just look at the MsgDeliverEvent() function and there was an example
in which client created a channel to get pulse, but server also has a
name registered. So client sned to server and receives pulse on his own
created channel. How is that?
The client is sending on the Server’s channel.
The client channel is used only to receive the notification pulse.
The client is sending on the Server’s channel.
The client channel is used only to receive the notification pulse.
So if you want to send, you only attach to server’s channel, but if you want
to receive you must create your own channel. Am I right? And messages always
go to one direction as I know, so clients always attaches to server
channels?
The client is sending on the Server’s channel.
The client channel is used only to receive the notification pulse.
So if you want to send, you only attach to server’s channel, but if you want
to receive you must create your own channel. Am I right? And messages always
go to one direction as I know, so clients always attaches to server
channels?
Actually, it is not strictly necessary. You can do what they call ‘reply
driven’ messaging, but it makes sense when ‘clients’ are not so much clients
as they are ‘worker bees’. They start up and ‘report to duty’ by sending
message to the ‘tsar’ (and become blocked waiting for reply). When a work
needs to be done, the tsar replies, they do the work and send a message
with completion/results. Et cetera, et cetera…
This used to be popular with QNX4, but with QNX6 workers are usually done as
threads and setting up channels is a bit more cumbersome than it was with
QNX4. However messages are still the fastest communication method, even
between threads, people just tend to assume that shared memory with
semaphores would be faster (they aren’t - I did benchmarks).
Important thing to take away is that messaging is not really
uni-directional. Replies can carry data. Logically it is right thing to do
to have clients attach to server (because they can locate single service)
but if they are all within a process then location is not an issue and you
can do whatever you want.
Have you looked at the new async IPC facilities in 6.3?
Tell you what; if you want to pay for postage only (CAD$25) I can airmail
you
a slightly damaged “Getting Started with QNX Neutrino” book. This will
answer
a large number of your questions…
Tell you what; if you want to pay for postage only (CAD$25) I can airmail
you
a slightly damaged “Getting Started with QNX Neutrino” book. This will
answer
a large number of your questions…
> > if you want to pay for postage only (CAD$25) I can airmail you
> When I must pay for it? At receive time or do I need credit cards?
VISA/Mastercard only, fax to +1 613 599 8317 along with your shipping
information, phone number, expiration date, and name of cardholder.
Unfortunately, you must pay before shipping. Airmail is about 2-3
weeks, and there is no tracking number or guarantee…
Cheers,
-RK
> Best regards,
> Darius
Cheers,
-RK
–
[If replying via email, you’ll need to click on the URL that’s emailed to you
afterwards to forward the email to me – spam filters and all that]
Robert Krten, PDP minicomputer collector http://www.parse.com/~pdp8/