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
