can be updated by another node… What guarantees do I have about what all other nodes see? Specifically I mean programming models that provide some kind of consistency guarantee. Example scenario:
object/datum that can be updated by another node… What guarantees do I have about what all other nodes see? Specifically I mean programming models that provide some kind of consistency guarantee. Often a developer assumes that they want strong consistency (everyone can see the same state). But sometimes weak consistency is good enough (not every node needs to be in sync before computation can resume)
provide some kind of consistency guarantee. In the past decade or so, thinking about controlling consistency by way of a programming model has come out of a famous impossibility result:
CRDTs choose sides. Such models sacrifice consistency in favor of availability. CRDTs (Conflict-free replicated data types.) (People like to call these AP) Think: Data structures that can be replicated over many nodes. When one node updates its replica, a CRDT guarantees that eventually all replicas will be eventually consistent.
is also work experimenting with other edges of that triangle. Meiklejohn’s work on Spry explores whether there’s other design points in the space, e.g., CA. “Spry is a programming model for building applications that want to tradeoff availability and consistency at varying points in application code to support application requirements.”
is also work experimenting with other edges of that triangle. Meiklejohn’s work on Spry explores whether there’s other design points in the space, e.g., CA. “Spry is a programming model for building applications that want to tradeoff availability and consistency at varying points in application code to support application requirements.” Can add bounded staleness and freshness requirements via annotations!
to choose from multiple consistency options in one application? • invokeWeak(operation) • invokeStrong(operation) • invoke(operation[, levels]) Give the user different APIs depending on the sort of consistency they’re after! Correctables They provide incremental consistency guarantees by capturing successive changes to the value of a replicated object. Applications can opt to receive a fast but possibly inconsistent result if eventual consistency is acceptable, or to wait for a strongly consistent result.
message send to the wrong service! Can be thought of as types for communication protocols That is, if a program type checks, then it’s guaranteed to follow the defined communication protocol. More concretely:
message send to the wrong service! Can be thought of as types for communication protocols Binary & Multiparty Static & Dynamic That is, if a program type checks, then it’s guaranteed to follow the defined communication protocol. More concretely: Many variants of session types:
⊕ { EHLO: !Domain.!FromAddress.!ToAddress.!Message.SMTPClient QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Client side:
⊕ { EHLO: !Domain.!FromAddress.!ToAddress.!Message.SMTPClient QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Client side: means: select between the following two branches
⊕ { EHLO: !Domain.!FromAddress.!ToAddress.!Message.SMTPClient QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Client side: EHLO: send (!) domain, from address, to address, and the message. Repeat. means: select between the following two branches
⊕ { EHLO: !Domain.!FromAddress.!ToAddress.!Message.SMTPClient QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Client side: EHLO: send (!) domain, from address, to address, and the message. Repeat. QUIT: protocol is over. means: select between the following two branches
end } SMTPServer = & { EHLO: ?Domain.?FromAddress.?ToAddress.?Message.SMTPServer QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Tiny example of implementing SMTP: Client side: Server side:
end } SMTPServer = & { EHLO: ?Domain.?FromAddress.?ToAddress.?Message.SMTPServer QUIT: end } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Tiny example of implementing SMTP: Client side: Server side: means: offering a choice between the following two branches
~> () fun smtpClient(c, from, to, msg) { var c1 = select EHLO c; var c2 = send(getDomain(from), c1); var c3 = send(from, c2); var c4 = send(to, c3); var c5 = send(message, c4) var c6 = select QUIT c5; close c6 } great introduction to session types by Simon Fowler: http:/ /simonjf.com/2016/05/28/session-type-implementations.html Tiny example of implementing SMTP: Implementation of the client: (Implemented in Links)
…operate under partial deployment • …be transparent (don’t touch communication) • …be language agnostic • …should accommodate the loose coupling of modern services and be extensible with wire protocols.
for Software Systems Marc Shapiro Sorbonne- Université-LIP6 & Inria ! " # Alexy Gotsman IMDEA Software Institute$ Sebastian Burckhardt Microsoft Research % Tom Van Cutsem Nokia Bell Labs & Suresh Jagannathan Purdue University % Patrick Eugster University of Lugano ' James Cheney University of Edinburgh ! Wolfgang De Meuter Vrije Universiteit Brussel Tony Garnock-Jones University of Glasgow ! Other folks active in this space
heathermiller
matsuo_atsushi
k1mu21
kntkymt
kajitack
j5ik2o
kn_to_maxpno
takter00
seosoft
bazlur_rahman
nrslib
ukin0k0
hollycummins
thekraken
eileencodes
philnash
bluesmoon
greggifford
reverentgeek
joshbly
yeseniaperezcruz
codingconduct
geoffreycrofte
keavy
garrettdimon
