Nnamdi Kohn <firstname.lastname@example.org> wrote:
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
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.