[racket] Marketplace: A language for network-aware programming

Hi Ray,

On 2013-05-30 12:53 PM, Ray Racine wrote:
> Very happy to see this.

:-)

> What is the general assumption, if any, regarding message delivery
> guarantees?  Guaranteed, Once-And-Only-Once, At-Most-Once.  And Message
> Ordering.  Say between 2 physical node Ground-VMs across a network?
> Node 1 - Process A - sends M1 - sends M2  ----> Node 2 - Process B
> always consumes M1 before M2?

TLDR: guaranteed, order-preserving delivery within a single ground VM.
Caveats apply :)

Within a ground-VM you get what lots of people would call "guaranteed"
delivery which in most systems is really a kind of "at most once"
because the receiving endpoint can fail during processing, which is hard
to tell apart from delivery failure or no-one having been listening at
the time. In Marketplace we think that presence and absence will help
distinguish delivery failure from service failure.

With regard to ordering, you get (within a ground-VM) what is usually
called something like pathwise order preservation: if two messages are
sent in order by one process and travel the same route to their
destination, they appear in order at the receiver. Actions from a
process are executed in order by its VM. That said, often intermediate
paths do vary and so this ordering guarantee is usually dangerous to
rely on in general. Hardly any middleware gets this right (including, at
present, Marketplace).

Regarding larger systems, connected by TCP or UDP or multicast or
whatever: no guarantees at all. Whatever the transport provides. We are
working on this. In particular, what is a good way of integrating
specification of QoS properties into the language? Where should the
resulting logic and state properly be placed? How should delivery
failure and flow control be signalled to the upstream applications? etc.

> Also rather curious on details of Marketplaces' approach to
> "Let-It-Fail" semantics and Nanny monitoring / restarting of processes.

We've been following the Erlang approach and finding it works out just
as well as it does for Erlang. Absence notifications work like exit
signals/process monitors. We haven't abstracted out a supervisor-like
pattern yet the way OTP has, but it's very doable.

> And it's in Typed Racket too.  Double plus good.

Watch out for typed/untyped boundaries, but yes :-)

Regards,
  Tony