PULSES and MESSAGES at process termination

Hello,

I have a server (server1) that created a channel (CHID) with ChannelCreate()
and a connection (COID) to another server (server2) with ConnectAttach().
When I terminate (e.g. with CTRL-C) server1 that had been RECEIVE_BLOCKED on
its CHID before, server1 sends a message (and a pulse) onto its connection
(COID) to server2 before termination. Is this normal behavior? If it is, how
can I detect this termination on that remote channel (CHID) of server2
connected to COID of server1?
I’ve tried it with checking for the reception of a _PULSE_CODE_UNBLOCK on
the remote server2, as MsgReceive() returned a rcvid of 0. This pulse didn’t
show up. But at first there arrives a message from server1 and after that
some other pulse from server1.

Who can help me detecting and correctly handling the termination of such a
connected server1? Where could I find literature about this specific issue
of termination and message passing?

Regards.

Nnamdi

Nnamdi Kohn <nnamdi.kohn@web.de> wrote:

Hello,

The documentation for ChannelCreate() mentions most of the pulses
you will get, based on the flags you set.

I have a server (server1) that created a channel (CHID) with ChannelCreate()
and a connection (COID) to another server (server2) with ConnectAttach().
When I terminate (e.g. with CTRL-C) server1 that had been RECEIVE_BLOCKED on
its CHID before, server1 sends a message (and a pulse) onto its connection
(COID) to server2 before termination. Is this normal behavior?

If you are explicitly calling ConnectAttach(), then you should always pass
the _NTO_SIDE_CHANNEL value in the 4th (index) parameter. e.g.:

ConnectAttach( _ND_LOCAL_NODE, pid, chid, _NTO_SIDE_CHANNEL, 0);

But, I would suggest looking at name_attach() and name_open() function
calls as well. They use registered names for client/server to locate
each other, rather than having to “know” the right pid/chid (e.g.
through a parent-child relationship or such.)

The message you see is, almost definitely, an IO_CLOSE message as
your coid is in the file descriptor (fd) range, and this is defined
behaviour for file descriptors.

The pulse is probably a disconnect pulse, telling server2 that a
client has gone away – though you usually have to request this
pulse by setting a channel flag on channel creation.

If it is, how
can I detect this termination on that remote channel (CHID) of server2
connected to COID of server1?
I’ve tried it with checking for the reception of a _PULSE_CODE_UNBLOCK on
the remote server2, as MsgReceive() returned a rcvid of 0. This pulse didn’t
show up. But at first there arrives a message from server1 and after that
some other pulse from server1.

To detect the client going away, you have to set the _NTO_CHF_DISCONNECT
on server2’s ChannelCreate() and this will send you a _PULSE_CODE_DISCONNECT
to let you know that server1 (server2’s client) has gone away.

_UNBLOCK pulses will only occur if you have received a message from a
client, and not replied to it yet, and the client tries to go away while
still REPLY blocked on your server.

That is: UNBLOCK is for a currently active operation being cancelled, whether
or not the client actually goes away, DISCONNECT is for a client that goes
away anytime.

Who can help me detecting and correctly handling the termination of such a
connected server1? Where could I find literature about this specific issue
of termination and message passing?

Hope the above helps a bit. I’m not sure the above stuff is very
well documented anywhere, actually. The bits & pieces are given in
detail, but I don’t think there is any sort of synthesis document
that tells what to do & why to do it.

-David

David Gibbs
dagibbs@qnx.com