“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:apbnuv$kds$1@nntp.qnx.com…
OK. Kevin actually send me an email explained their system and what they
are
tring to do. After some mindstorm with our CAOs and old timer FLEET
expert, let me put all the thoughts together > 
Heh…I pressed the wrong button when I went to reply to you…I was meaning
to post it to the ng, but alas, it filled up your mail box…sorry about
that It was a bit too wordy anyway…that’s why I didn’t post it here.
- MsgDelieverEvent() is not “reliable” in the manner of “delievering
event”, local or remote.
In local, MsgDelieverEvent() look at the client (the destination of
deliverring), and queue
the event, return success. The client could then gone, and event
delievere will fail late.
That’s actualy just fine. We don’t need to know that the client actually
received it (i.e. acknowledged it and acted upon it) just that it got queued
to the client, or that it reached the remote node where we can be fairly
sure it would be queued.
In remote, MsgDelieverEvent() won’t be able to look at the client (at
remote site), it just
successed, handing data to QNET. QNET then move the event cross
network,
and
deliever it to client. Either step could fail, and server won’t know.
So the question goes to, is it important to KNOW that a client is
existing at the moment
of MsgDelieverEvent() ?
No it is not important. Obviously MsgDeliverEvent returns in error in the
local sense if the client doesn’t exist, and the traffic that would have to
occur to insure a client existed over network is an unreasonable demand.
However, one can reasonably expect that if the event makes it across the
wire, that it won’t get lost because of ambiant noise or a link failure, and
thus the remote qnet will attempt to find the client and deliver it to that
client. If the client has died, then there is no reason to care. It’s just
that I think there needs to be some indication that the event has reached
the remote node.
- Kevin mentioned FLEET and remote proxy trigger. It turns out FLEET did
the same thing.
After Trigger() a remote proxy, and return EOK, you can only sure the
VC is existing.
Data is not moving accross network at that time, and could still fail
later.
Yes…and if a client has died, the VC is cleaned up. I believe that the vc
becomes unavailable because of a broken link, and the proxy can’t make it
across the network, Trigger() will indicates this. It is this type of
functionality upon which we rely…
…
- In QNX6, if a clint (who have an open connection with a server) goes
away, the server
will get told (_NTO_CHF_DISCONNECT). This means the server will
“reliable” know
whenever a client (local or remote) goes away. If you using resource
manager framework,
this flag is automaticly set on channel for you.
I remember a conversation I had with someone who indicated that the
_NTO_CHF_DISCONNECT was not a reliable way of determining if a client gets
disconnected. I don’t remember the details of the conversation, but I
believe I was having problems with clients that were reply blocked on a
server and was concerned because I could not force the clients to die as the
server would not let them go (I can’t remember the flag that is set that
allows a server to not let go of a client). If I remember correctly, I was
told that _NTO_CHF_DISCONNECT was not 100% reliable, and so it was necessary
that servers hold on to clients until they wish to reply to them so as to
prevent duplicate rcvid from messing things up.
However, it’s not that I care about a client going away, I care about the
ability to get the event from the server’s node to the remote node with
verification that it at least arrive at the remote node. We can assume that
if the event arrives at the remote node and the client is runnig, that it
will then get queued up at the client. The problem occurs if the client is
running and the event gets lost because of network interruptions, I want to
be able to recover gracefully from it.
- You seems more concern of QNET can’t move data cross network. In
general,
QNET
provide reliable data transfer. if data can’t be reliable transfered
(network down, remote
node shutdown, nic error), QNET will decided the other node is no
longer
exist, and
wipe out ALL the clients from that node, which in turn, the server
will
get it’s DISCONNECT
pulse.
(The are more complicate things happened in multiple interface, and
QoS,
but …)
Is the DISCONNECT pulse guaranteed to be delivered to the server in this
situation? If not, under what circumstances might a server miss a
DISCONNECT pulse?
I know you guys are very busy over there, so I really appreciate you time
xtang…take care,
Kevin
-xtang
Kevin Stallard <> kevin@ffflyingrobots.com> > wrote in message
news:apae5a$25s$> 1@inn.qnx.com> …
See one of the aspects of QNX that I argue a lot is the fact that QNX
can
be
very resource aware. If I’m having to clog the network because I
constantly
have to query for state information, then I can’t use that anymore as a
reason and they might as well use streaming UDP (ick!).
Additionally…when it comes to state behavior…if a remote process is
relying on accurate state change information and has to query for it, it
is
possible that states could change w/o the client knowing (aliasing
problems…not sampling fast enough). This is why there has to be a
way
to know if an event at least made it across the wire. If it makes it
across
the wire I think we can safely say it will make it to the client if it
is
still running…if it isn’t running…then, yes, there is no need for
concern.
Kevin
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:apaa3j$lh9$> 1@nntp.qnx.com> …
Kevin Stallard <> kevin@ffflyingrobots.com> > wrote in message
news:apa662$nec$> 1@inn.qnx.com> …
Quote from the mannual under the MsgDeliverEvent entry:
Quote
Native networking
When you use MsgDeliverEvent() to communicate across a network, the
return
code isn’t “reliable”. In the local case, MsgDeliverEvent() always
returns
a
correct success or failure value. But since MsgDeliverEvent() must
be
nonblocking, in the networked case, the return value isn’t
guaranteed
to
reflect the actual result on the client’s node. This is because
MsgDeliverEvent() would have to block waiting for the communications
between
the two npm-qnets.
Generally, this isn’t a problem, because MsgDeliverEvent() is for
the
benefit of the client anyway – if the client no longer exists, then
the
client obviously doesn’t care that it didn’t get the event. The
server
usually delivers the event and then goes about its business,
regardless
of
the success or failure of the event delivery.
/Quote
Question:
Will the error code indicate a communications failure? In other
words,
will MsgDeliverEvent() fail if the link to the destination node is
down
or
some other error prevented the remote npm-qnet from receiving the
request?
No. In fact it seems it will never fail cross QNET. (Not if something
like
the
delievered event pointer is point to invalid memory space)
I don’t care about notification that the client on the remote node
actually
received it, but I do think it is important that the event at least
reach
the remote node (qnet on the local node indicates a successful
transmission).
Why? What the difference of the event is reached the other node or not
?
The idea of QNET is your application should not aware it is talking
cross
network or not…
-xtang
\