Tim Watson

I would suggest enabling tracing on the server node, to see if the messages are actually arriving at all. Look at http://hackage.haskell.org/package/distributed-process-0.5.5.1/docs/Control-Distributed-Process-Debug.html for setting up tracing on either node (or...

Ok I'll take another look this week and see if I can discern why the send us t taking place...

Isn't *

Quite possibly, we could be looking at a bug in library code (network transport, or even network itself, or something else) that is environment specific. Let me have a think...

Okay I've been unable to reproduce on a linux vm, but I still haven't quite nailed the instrumentation issue. I'm thinking it might be worth enabling some debugging features in...

So... I think one possibility is that the server dies between invocations of the client, or between the lookup and send. I'm adding some instrumentation to the server framework, so...

So do you see error messages print for the failing call? If you set up a monitor for the remote server do you see it die? Or is this a...

@qnikst - @dcoutts and I discussed using binary's buffering features to assist with that at one point, but not sure if that was it. But if we're saying the send...

Also, would the OP mind re-running this with the logging to the console, so we can see all the events separately. I note that the client logs you've pasted appear...

Wait... @qnikst don't you mean message encoding? How can message decoding appear in the main thread? Do we mean conversion from bytes to `Message` occurs in the mode controller's thread?...