RE: IKC reconnect

On 19-Mar-2010 roger bush wrote:
> Is it similarly possible to reconnect on a failed call (at the cost
> of some latency)?  Or are there other side effects from this that
> are unwanted?

If by "failed call" you mean "IKC request to a disconnected remote kernel" then
currently, no.  But it would be relatively trivial to add an monitor for that.

> This seems to be the standard way to do things over TCP/IP, since we
> discover sockets are dead via an attempt to read them.

With IKC, you can know before hand when something has disconnected.  But there
is a race condition between posting a request and getting the
monitored disconnect event.  In fact, the "monitor for failed request" would
also have a race condition unless I can be very clever about detecting failure
were the disconnect happens after the Responder has done it's work.

This might not be clear.  Here's a list of the steps a request goes
through before "hitting the wire" :

1- Your session
2- IKC::Responder
3- IKC::Channel
4- Wheel::ReadWrite
5- Driver::SysRW

If the disconnect happens before step 2, then adding a monitor for it is
trivial.  If the disconnect happens during 3, 4 or 5, then it will be trickier
to detect. Especially writing test cases for it.

Thinking furthur, if you don't trust a IKC connection to stay open, you need
some sort of 'acknowledge' from the other side.  And that is currently beyond
the scope of IKC.

-Philip