New distributed-process (Cloud Haskell) backend/transport design and prototype
Duncan Coutts
A couple months ago we all had an interesting discussion [1] about the
design of a transport layer interface for a new distributed-process
(Cloud Haskell) implementation.
[1]:
http://groups.google.com/group/parallel-haskell/browse_thread/thread/c149a84b17409a11
Since then my colleague Nick and I have been working on prototyping and
incorporating the feedback on our initial design proposal.
We now have some code ready for people to look and poke at, and in
addition we have a new design document. We would now like to invite
feedback on both.
Code
------
https://github.com/haskell-distributed/distributed-process
While we consider this work to be a prototype, we have a number of
examples which demonstrate the interface at work, which can be found in
the `/distributed/examples` directory in the main repository.
In particular, we have not paid any attention to exception handling at
this stage, and would appreciate comments specifying the failure
behaviour.
Design
--------
https://github.com/haskell-distributed/distributed-process/wiki/New-backend-and-transport-design
We have tried to accommodate the suggestions made in the initial thread,
and we'd appreciate any feedback or comments you might have.
The most salient differences from the original are:
* a concrete system design allowing multiple backends,
configuration and peer discovery/creation
* a concrete transport interface
* a proposed solution to the problem of how to supply
transport-specific connection options (e.g. all the crazy TCP
socket options)
* four different connection types: reliable, unordered, unreliable
and multicast
* vectored send/receive
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Facundo Domínguez
I've been following the discussion about the abstract transport API
and find some points unclear. A summary follows:
1. Which motivation is there for the connection model? It is not very
obvious why a general
purpose abstract transport API should provide unidirectional N-1
connections. So far I've not been able to explain this to myself in
convincing words.
2. Does this model force a receiver to accept packets from anyone
having its address? Is this desirable?
3. I'm curious about the troubles of implementing lightweight
connections over TCP. Would it be possible to ask for a more detailed
statement of the issues?
Best,
Facundo
On Jan 18, 9:19 am, Duncan Coutts <dun...@well-typed.com> wrote:
> All,
>
> A couple months ago we all had an interesting discussion [1] about the
> design of a transport layer interface for a new distributed-process
> (Cloud Haskell) implementation.
>
> Since then my colleague Nick and I have been working on prototyping and
> incorporating the feedback on our initial design proposal.
>
> We now have some code ready for people to look and poke at, and in
> addition we have a new design document. We would now like to invite
> feedback on both.
>
> Code
> ------
>
> https://github.com/haskell-distributed/distributed-process
>
> While we consider this work to be a prototype, we have a number of
> examples which demonstrate the interface at work, which can be found in
> the `/distributed/examples` directory in the main repository.
>
> In particular, we have not paid any attention to exception handling at
> this stage, and would appreciate comments specifying the failure
> behaviour.
>
> Design
> --------
>