New distributed-process (Cloud Haskell) backend/transport design and prototype

127 views
Skip to first unread message

Duncan Coutts

unread,
Jan 18, 2012, 6:19:26 AM1/18/12
to parallel...@googlegroups.com
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.

[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

unread,
Jan 30, 2012, 8:35:15 PM1/30/12
to parallel-haskell, Peter Braam, Rich Lyman
Hi there,
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.
>
> [1]:http://groups.google.com/group/parallel-haskell/browse_thread/thread/...
>
> 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-b...
Reply all
Reply to author
Forward
0 new messages