OK. I got two rather long responses to my post. Both miss a subtil point. Before going in to it, I would like to point out that I've been thinking about this problem for over 10 years. So I've put a lot of thought into it.
Now, the full IKC stack : 1- Your session 2- IKC::Responder 3- IKC::Channel 4- Wheel::ReadWrite 5- Driver::SysRW 6- OS kernel 7- A series of tubes and then 6-1 in reverse. Currently, the responder does not keep track of a request for longer then handing it to a Channel. And the Channel doesn't track the request after handing it to the Wheel. They all hand it on like a hot potato. But then we bump into the law of leaky abstractions. Even after SysRW has handed the request to the kernel we have no guarantee the entire request makes it through the series of tubes to the remote OS, hence up the chain to the remote Responder. Your request could very easily span serveral TCP/IP packets, some of which could be dropped, some not. What is needed is at least for the destination Responder to send an acknowledge back the the originating Responder. Or ideally the destination Session. IKC could also do a better job at detecting local errors. Now if the Responder never receives this acknowledge, then what? Do we try again? Wait until conditions are more favorable? Do we advise the sending session there was an error? Do we throw the request away? Which of these possibilities is the best is *application* *specific*. Not only that, it is specific to each request. Currently, there is no way in POE to add meta-data to a request. And if we do something ourselves, we loose one of IKC's goals of being transparent, making remote sessions look like local. I've been pestering Rocco for over 10 years about request meta-data. His response is that this is outside of the POE's core goal and that there is no clear consensus in the community on how this should be done. I do not wish to reopen that discussion. For a while POE::Stage was going to be the answer. Now we have Reflex, which contains some intersting magic. But Rocco has other things going on, so neither are production ready. I'm not blaming Rocco at all; IKC solves the problem I wrote it for (web server talking to an app server) and is part of my core products. I don't have time to work on the Final Solution, much as would enjoy doing so. But the Final Solution now has a name, now : Message Queue. If you want to go that route, look at AMQP and RabbitMQ and so on. But this post is already to long to go into this. IKC1 was going a very similar route to AMQP, until I detected a Heisenbug. But I ran out of tuits and I never sovled it. I now suspect that the bug was might have been the SIGCHLD race condition. Back to the discussion at hand : maybe one of you wants to implement POEx::IKC::Connection, which will handle IKC disconnect/reconnect. And POEx::IKC::Queue, which will handle IKC request queuing, acknowledge, retry and so on. It occurs to me that request meta-data could be configured before hand: POEx::IKC::Queue would implement several queues, each with different configurable characteristics : hot potato queues that throw requests away if there is no ACK all the way to persistant queues that save a request to disk and retry until the request is manually removed from the queue. I would be more then glad to make any changes to IKC itself that would make these modules easier to implement. Something along the lines of hooks into the Responder. -Philip
