At 17:45 27/02/03, Alex Rousskov wrote:
jfc,
It looks like you are still missing the point:
I think you also does, due to my incapacity to explain it
in your own protocol words.
So, let stop this for the time being. We will keep it mind.
What I know is as a developper in my specific environment
I needed it and I suppose that in the project which takes
shape we will use it. But much to early. Also you may be
right about it being ill construed. The development I refer
to is now 15/7 years old, initially very rustic and empirical.
I just know what I did with it :-)
<skip>
The simplest example is when the other side already zapped the
transaction in question. It cannot zap it again, yet the message
explicitly tells it to do so.
hmmmm. Sorry I lead you to a wrong understanding.
My use/understanding of zap is initial pipe oriented.
Clean the "thing" tree from that pipe.
Using 100 times zap is totally acceptable. Actually this is
the best way to synchronize. zap means swallow everything
related to this pipe, clean it. Nothing in there, what ever it was.
Clean buffers. Signal attached tasks to die propagate along
the pipes all over the network. Or the equivalent (I use the
image of my old QNX based system). May be I was wrong
in assuming that it corresponded to your commands.
Exemple of dispatcher rule:
if (ball==zap)
{
send_zap(piper);
clean_reset();
exit();
}
So for example zap 0 would kill the network and restart
the network establishment negociations, etc. Next to power
down it is the "reboot" of the network.
Is this clearer?
jfc