I think he was asking why is there a difference between MsgSend
and MsgSendv, rather than why is there a difference between srclen
and msglen.
I thought that MsgSend == MsgSendv in terms of behaviour, except
that one takes a linear buffer and one takes an IOV. (I don’t
have access to the docs here, so in case you are right, and
_NTO_CHF_SENDER_LEN really does do something magically different
between MsgSend and MsgSendv on the client side, I apologize in
advance )
BUT in last case server prints:
srclen:40 msglen:40
WHY THOSE DIFFERENTES IN
msg_info.srcmsglen
???
–
Respectfully Yours
vasa
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
I think he was asking why is there a difference between MsgSend
and MsgSendv, rather than why is there a difference between srclen
and msglen.
I thought that MsgSend == MsgSendv in terms of behaviour, except
that one takes a linear buffer and one takes an IOV. (I don’t
have access to the docs here, so in case you are right, and
_NTO_CHF_SENDER_LEN really does do something magically different
between MsgSend and MsgSendv on the client side, I apologize in
advance > > )
_NTO_CHF_SENDER_LEN does something different. In fact, unless you
set this flag, srcmsglen does not have to have a meaningful value.
Or, to put it another way, unless you set this flag, srcmsglen is
undefined – it could be anything.
Basically, setting this flag asks the kernel to sum the iov_len for
all the (possibly multiple) parts of a multi-part message – otherwise
the kernel takes the shortcut of not doing the summation.
Apparently it fills in the value of the first part if you don’t
specify it – this will actually work fine for the MsgSend() case,
as then there is only one part, but not for a multi-part message.
Of course, you shouldn’t depend on this behaviour – if you want
this field to be valid, set the flag in your ChannelCreate() call.
Robert Krten <> nospam83@parse.com> > wrote:
I think he was asking why is there a difference between MsgSend
and MsgSendv, rather than why is there a difference between srclen
and msglen.
I thought that MsgSend == MsgSendv in terms of behaviour, except
that one takes a linear buffer and one takes an IOV. (I don’t
have access to the docs here, so in case you are right, and
_NTO_CHF_SENDER_LEN really does do something magically different
between MsgSend and MsgSendv on the client side, I apologize in
advance > > )
_NTO_CHF_SENDER_LEN does something different. In fact, unless you
set this flag, srcmsglen does not have to have a meaningful value.
Or, to put it another way, unless you set this flag, srcmsglen is
undefined – it could be anything.
Basically, setting this flag asks the kernel to sum the iov_len for
all the (possibly multiple) parts of a multi-part message – otherwise
the kernel takes the shortcut of not doing the summation.
Apparently it fills in the value of the first part if you don’t
specify it – this will actually work fine for the MsgSend() case,
as then there is only one part, but not for a multi-part message.
Of course, you shouldn’t depend on this behaviour – if you want
this field to be valid, set the flag in your ChannelCreate() call.
Well, that’s it, I give up my product support hat; I’m 0 for 2 today
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Well, that’s it, I give up my product support hat; I’m 0 for 2 today > > >
Thanks for clearing that up Dave!
My single sentence wasn’t sufficient? >
Cryptic.
-RK
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.