Hi,
Is it possible to get the pid tid,etc… from a known rcvid.
I think the OS knows these informations.
Thanks,
Alain.
ConnectClientInfo()
-xtang
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote in message
news:3E427592.8050800@icbt.com…
Hi,
Is it possible to get the pid tid,etc… from a known rcvid.
I think the OS knows these informations.Thanks,
Alain.
Xiaodan Tang <xtang@qnx.com> wrote:
ConnectClientInfo()
No – ConnectClientInfo() takes a scoid.
-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E427592.8050800@icbt.com> …
Hi,
Is it possible to get the pid tid,etc… from a known rcvid.
I think the OS knows these informations.
IF the client is still blocked:
MsgInfo()
I do not know if MsgInfo() is valid after you have replied, I would
expect not, in that case, if the client is no longer blocked, I do
not know of a way.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Sounds strange but it makes me think about another question for the one
I didn’t had a clear answer some times ago!
What does the rcvid is for in MsgDeliverEvent(), because that function
can work curiously (sending the event to someone else) if the original
client is dead.
Thanks,
Alain.
David Gibbs a écrit:
Xiaodan Tang <> xtang@qnx.com> > wrote:
ConnectClientInfo()
No – ConnectClientInfo() takes a scoid.
-xtang
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E427592.8050800@icbt.com> …
Hi,
Is it possible to get the pid tid,etc… from a known rcvid.
I think the OS knows these informations.
IF the client is still blocked:MsgInfo()
I do not know if MsgInfo() is valid after you have replied, I would
expect not, in that case, if the client is no longer blocked, I do
not know of a way.-David
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Sounds strange but it makes me think about another question for the one
I didn’t had a clear answer some times ago!
What does the rcvid is for in MsgDeliverEvent(), because that function
can work curiously (sending the event to someone else) if the original
client is dead.
I know that rcvid’s do get re-used.
I would GUESS that it is a look-up into the client list for the
process using the rcvid, plus tid information.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
If it’s the case, MsgDeliverEvent() should check if rcvid is still valid
before sending the pulse anywhere else!
But it’s also possible that MsgDeliverEvent() only take care of
informations stored in the event structure.
Even in that case, isn’t it an error to not take care of a valid coid.
Remember, we where talking about security problems in the ‘timer pulses’
discussion thread, where you complained about the ability to send a
pulse to anybody even if we have not the rights. This is the same
problem here.
A server die, the coid gets free, it’s given to the next running program
which receive the events previously programmed for the died server.
regards,
Alain
David Gibbs a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Sounds strange but it makes me think about another question for the one
I didn’t had a clear answer some times ago!
What does the rcvid is for in MsgDeliverEvent(), because that function
can work curiously (sending the event to someone else) if the original
client is dead.
I know that rcvid’s do get re-used.I would GUESS that it is a look-up into the client list for the
process using the rcvid, plus tid information.-David
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
If it’s the case, MsgDeliverEvent() should check if rcvid is still valid
before sending the pulse anywhere else!
But, it is valid. It is just valid for a different client. The kernel
CAN’T know which event was “supposed” to be associated with which rcvid.
Which, of course is a problem…
Remember, we where talking about security problems in the ‘timer pulses’
discussion thread, where you complained about the ability to send a
pulse to anybody even if we have not the rights. This is the same
problem here.A server die, the coid gets free, it’s given to the next running program
which receive the events previously programmed for the died server.
I’m not sure exactly that the coid getting re-used is a problem – that
is normal and expected behaviour. (fds get re-used, coids and fds share
that behaviour). But the rcvid getting re-used is messy, and in combination
with a coid that might point somewhere again, could get real messy.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
If it’s the case, MsgDeliverEvent() should check if rcvid is still valid
before sending the pulse anywhere else!But, it is valid. It is just valid for a different client. The kernel
CAN’T know which event was “supposed” to be associated with which rcvid.Which, of course is a problem…
Hm…it may be up to the server to deal with.
– the server must request disconnect notification
– the server must associate the saved rcvid with a scoid
– if the server receives a disconnect notification for which it has
a saved rcvid & event, it must clear them out and stop delivering/
not deliver that notification again
This probably should be documented with an example.
Remember, we where talking about security problems in the ‘timer pulses’
discussion thread, where you complained about the ability to send a
pulse to anybody even if we have not the rights. This is the same
problem here.A server die, the coid gets free, it’s given to the next running program
which receive the events previously programmed for the died server.I’m not sure exactly that the coid getting re-used is a problem – that
is normal and expected behaviour. (fds get re-used, coids and fds share
that behaviour). But the rcvid getting re-used is messy, and in combination
with a coid that might point somewhere again, could get real messy.
If server clears rcvids (see above), that clears up much of the problem.
A coid on the client side will not be re-used until the client calls
ConnectDetach() – if the same client with an outstanding notification
from a server to a coid detaches that coid, then re-attaches it elsewhere,
it must also clean-up (remove, or request cancellation) of any pending
notification. Otherwise this is a programming error on the client side.
(The parallel - if a program closes a fd (say 0) then opens that elsewhere
later, say to a raw disk partition, or a tcp socket sending control data,
then accidentally calls printf() later, then this is a programming error.)
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.