MsgInfo() questions

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

Two questions about MsgInfo().

First, is there a difference between passing a _msg_info pointer to the
MsgReceive() functions and subsequently calling the MsgInfo() function?

The docs kind of imply that calling MsgInfo() can return more info then
passing the struct pointer. If that is true, what info isn’t available
if only passing the pointer to the MsgReceive() function?

Also, if there an equivlent method for determining the bytes received
in the reply message after a MsgSend()?

If not, is it ever possible that the reply is across a network and not
all bytes were actually transferred? {like in the original MsgSend() }

2

Bill Caroselli <qtps@earthlink.net> wrote:

Two questions about MsgInfo().

First, is there a difference between passing a _msg_info pointer to the
MsgReceive() functions and subsequently calling the MsgInfo() function?

The docs kind of imply that calling MsgInfo() can return more info then
passing the struct pointer. If that is true, what info isn’t available
if only passing the pointer to the MsgReceive() function?

If the client is reply blocked, and has been hit by a signal, and
the server is PPF_SIGCATCH (well, the Neutrino equivalent, forget the
name) the flags in the info of the later MsgInfo() can be checked to
see if that is true. (And there might be other stuff.)

Also, if there an equivlent method for determining the bytes received
in the reply message after a MsgSend()?

No. (The return value is often used for this.)

If not, is it ever possible that the reply is across a network and not
all bytes were actually transferred? {like in the original MsgSend() }

Not in a successful transaction (MsgSend returned success). If MsgSend()
fails due, possibly, to a network outage during the transfer, some of
the bytes in the reply buffer may have been filled in with data, but not
all.

The reason not all might be copied to the receive buffer is buffering,
essentially:
– on send, a certain amount is immediately copied accross the network
to the remote side and buffered there
– on MsgReceive() the locally buffered amount is copied into the
receive buffer, and the server unblocked immediately
– the server can then get the rest, by specifying a buffer to MsgRead()
the network stack need not buffer the data, so any amount can be
copied

Similarly, on reply – the entire reply buffer for the MsgSend() is available,
so the data can be copied in as the networking stack gets it, so io-net
doesn’t have to buffer it, so you will always get the full thing.

-David

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

3

David Gibbs <dagibbs@qnx.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
Two questions about MsgInfo().

First, is there a difference between passing a _msg_info pointer to the
MsgReceive() functions and subsequently calling the MsgInfo() function?

If the client is reply blocked, and has been hit by a signal, and
the server is PPF_SIGCATCH (well, the Neutrino equivalent, forget the
name) the flags in the info of the later MsgInfo() can be checked to
see if that is true. (And there might be other stuff.)

This makes sense.

Also, if there an equivlent method for determining the bytes received
in the reply message after a MsgSend()?

No. (The return value is often used for this.)

I can see this. I’d rather use it as an actual status. I guess it can
return two shorts, a status and a length (limited to 64k).

If not, is it ever possible that the reply is across a network and not
all bytes were actually transferred? {like in the original MsgSend() }

Not in a successful transaction (MsgSend returned success). If MsgSend()
fails due, possibly, to a network outage during the transfer, some of
the bytes in the reply buffer may have been filled in with data, but not
all.

The reason not all might be copied to the receive buffer is buffering,
essentially:
– on send, a certain amount is immediately copied accross the network
to the remote side and buffered there
– on MsgReceive() the locally buffered amount is copied into the
receive buffer, and the server unblocked immediately
– the server can then get the rest, by specifying a buffer to MsgRead()
the network stack need not buffer the data, so any amount can be
copied

Similarly, on reply – the entire reply buffer for the MsgSend() is available,
so the data can be copied in as the networking stack gets it, so io-net
doesn’t have to buffer it, so you will always get the full thing.

Here it gets interesting. So, I assume that the OS/netmanager will
guarantee that on the reply side, the blocked thread won’t be unblocked
until all bytes have been transfered (limited by my reply buffer size)
regardless of how big the transfer is. Correct?

Is there a limit to the size of a reply message?

One last question. If my reply buffer size is 1000 bytes and the server
replies with 1100 bytes, are those last 100 mytes lost? Is there any
way to read the subsequent 100 bytes? I assume not, but if yes, where
are they buffered?

4

I can see this. I’d rather use it as an actual status. I guess it can
return two shorts, a status and a length (limited to 64k).

You can actually use MsgError() for this sort of thing. So a normal reply
implies success, while a MsgError() can be used for reporting errors. As
the help states, MsgError() will cause MsgSend to return -1 and sets errno
for you. Tada!

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

5

Bill Caroselli <qtps@earthlink.net> wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
Bill Caroselli <> qtps@earthlink.net> > wrote:

Similarly, on reply – the entire reply buffer for the MsgSend() is available,
so the data can be copied in as the networking stack gets it, so io-net
doesn’t have to buffer it, so you will always get the full thing.

Here it gets interesting. So, I assume that the OS/netmanager will
guarantee that on the reply side, the blocked thread won’t be unblocked
until all bytes have been transfered (limited by my reply buffer size)
regardless of how big the transfer is. Correct?

I’m not sure exactly when the netmgr unblocks your server, but in essence
yes.

Is there a limit to the size of a reply message?

No more than on the size of a send message.

One last question. If my reply buffer size is 1000 bytes and the server
replies with 1100 bytes, are those last 100 mytes lost? Is there any
way to read the subsequent 100 bytes? I assume not, but if yes, where
are they buffered?

No different from QNX4, and no different from the local case. If you
reply with 1100 bytes into a 1000 byte reply buffer, 1000 bytes are
copied. The client is unblocked, the server is unblocked, no way to
get to the data.

In the server, you can set the channel flag _NTO_CHF_REPLY_LEN and
then look at info.dstmsglen to know how big the reply buffer is, and
not reply with more than that if you want.

-David

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