which closes the entire "bundle" of (outgoing and incoming) connections to another endpoint. Basically, "disconnect completely from this other endpoint" (a "heavyweight disconnect").
Once this is implemented we can resolve a TODO in `Control.Distributed.Process.Node`.
Comment:edsko:12/18/12 01:45:23 PM:
Yes, agreed on all the above. My main point is: don't rush into this one
Comment:hyperthunk:12/18/12 01:41:04 PM:
@edsko - we deal with these kinds of problems every day at RabbitMQ and they are indeed very tricky to get right. In fact, I'd say I spend > 30% of my engineering efforts hardening the broker against situations that arise because of unreliable networks, and that's just considering TCP/IP.
The problem with making this operation synchronous is that it can block for an arbitrary period of time, depending on the semantics of the underlying network/transport/protocol/etc. That's not good news when you're trying to shut down, upgrade, restart or whatever. One solution is timeouts, but then you're never sure just how long they should be and of course this should be a matter of policy. For connected protocols like TCP, using heartbeats is usually the right solution, with configurable parameters to control the frequency. Even for disconnected protocols this is usually a good idea.
Making this operation asynchronous is fine, in theory, but there would need to be some kind of completion callback or result on which the caller can block if required.
Comment:edsko:12/18/12 01:41:04 PM:
Comment:netogallo:12/18/12 12:12:45 PM:
Implementing such function does seem to require careful consideration since users will be expecting somewhat homogeneous behavior in all transports which might be tricky. I will probably return to this issue once I have better understanding about transports, especially since I am not a networks guy. Thanks for the valuable feedback, I believe this discussion will be very useful to tackle the problem, but for the moment I will review CH a little more to figure out where my skills can be most useful. Thank you for the feedback.
Comment:edsko:12/18/12 11:58:32 AM:
> Just realised - you're closing the connections to the other endpoint but not closing the local end!
Yes, this is not `closeEndpoint`. The `Network.Transport` API has this concept of a 'bundle' of connections between two endpoints. `closeConnectionTo` closes such a bundle in one go, without closing the endpoints themselves or connections they might have to other endpoints.
Note that that "in one go" is in serious need of expansion. How synchronous is this operation? What about data currently in the network? Etc. Etc. These are not easy questions to answer.