From 8fd23285329c84e0a22951d16e48c0e9eec41d11 Mon Sep 17 00:00:00 2001 From: Tony Garnock-Jones Date: Wed, 11 Jul 2012 11:57:25 -0400 Subject: [PATCH] Outline updates --- presentation/talk-outline.org | 160 ++++++++++++++++++++++++---------- 1 file changed, 112 insertions(+), 48 deletions(-) diff --git a/presentation/talk-outline.org b/presentation/talk-outline.org index a0f49f9..c35e478 100644 --- a/presentation/talk-outline.org +++ b/presentation/talk-outline.org @@ -4,6 +4,8 @@ #| +Desperately needs a name - "os-big-bang", "os2" + Outline ideas: - the core of the idea is pubsub and presence. conversational context - not raw messaging and actors. @@ -23,10 +25,6 @@ Recent work in Network Application Architecture. --------------------------------------------------------------------------- -Desperately needs a name - "os-big-bang", "os2" - -Intro: - Lots of systems, both formal models and practical implementations, work with messaging between actors or actor-like entities. Notably Erlang and the π-calculus. @@ -70,8 +68,8 @@ contracts, but I'm looking at it from a different angle: - how does a conversation start? Resource allocation - how are resources managed during a conversation? - Acknowledgement - Nacks + Responsibility + Error control Flow control - how do participants know when a conversation is over? Error/crash/exit signalling @@ -85,6 +83,9 @@ contracts, but I'm looking at it from a different angle: To experiment with this I've come up with a model operating system, and used it to implement a DNS caching proxy and an SSH server. + Whiteboard + Functional pub/sub + presence + The model operating system is based on multicast/pubsub, and also includes a construct for working with conversational context. I've been calling it "presence", since it's a generalisation of an idea @@ -96,6 +97,14 @@ and so has similar characteristics, including processes usually having first-order state - and recursive, meaning that instances of the kernel can run as user processes within another kernel instance. + - Gives a "thread" equivalent that composes + - Hide implementation detail: hide threads away in a nested-vm + with a private language + +There's a kind of hypervisor - which I'm calling a ground-vm - which +connects to the real world using Racket's CML-inspired event +mechanism. + Each process within an instance of the system has private state, and a collection of active endpoints. Again the terminology here is a bit loose, and while I usually think of endpoints as subscriptions or @@ -122,6 +131,25 @@ conversation(s). Role = 'Subscriber + 'Publisher + ... InterestType = 'Participant + 'Observer + 'SuperObserver +Motivate endpoints vs Erlang-style single mailbox + - The system should make it possible for programs that would + otherwise block on some external operation to remain responsive to + their normal inputs while waiting for the external operation to + complete. + +Topics are /just/ sets of messages. Hence, messages include their +topic. This is like packets being wrapped in a header to become a +packet at the next layer down. + +An endpoint includes not just a role and a set of messages, but also an /interest type/. + - participant + - observer/monitor + - "super"-observer/monitor + +Observers are useful for resource management. + +Example: Bank teller + The kernel runs a process in response to some external event, and it expects back a new process state and a list of actions that the process wishes the kernel to perform on its behalf. @@ -146,6 +174,12 @@ process wishes the kernel to perform on its behalf. groundVM :: (∃State . State × [Action]) → 0 groundVM bootProcess = ... +Example: TCP. Talk about the roles of observers. + - listener-factory: #:monitor 'everything + - connection-factory: #:monitor #t + - listener: #:monitor 'everything (to detect when counterpart goes away) + - connections: #:monitor #f + --------------------------------------------------------------------------- |# @@ -229,52 +263,81 @@ process wishes the kernel to perform on its behalf. + + + + +(define (connection-handler local-addr remote-addr) + (transition 'no-state + (role 'date-sender (topic-publisher (tcp-channel local-addr remote-addr (wild))) + #:state state + [(tcp-channel _ _ (tcp-credit _)) + (transition state + (kill))]) + (send-message (tcp-channel local-addr remote-addr + (string->bytes/utf-8 + (format "~a\n" (current-inexact-milliseconds))))))) + + + + + + + + + #| --------------------------------------------------------------------------- -Messages include their topics: topics are after all just sets of messages - - This means ground events are (cons/c evt/c any/c) - - This is the set of all possible responses to sync'ing on that event! - - I've scraped by with this so far, but because sync'ing has - side-effects, I'll eventually need better names for event requests - and responsibility transfer. +Talk about DNS and SSH + +DNS structure: + - timer + - udp + - server + - timer-relay + - query-id-allocator + - reader (server) + - writer (server) + + (server) + - error-logger + - respondent + + (proxy) + - reader (client) + - writer (client) + - packet-dispatcher + + packet-relay + - question-dispatcher + + question-handler + + glueless-question-handler + + network-query + +SSH structure: + - timer + - tcp + - listener + + session + - exception-handler + - event-relay + - timer-relay + - reader + - writer + - session + - application + - boot process + - ... any others + +Compare the "natural" structure of SSH with the structure using nested VMs + Whiteboard + Diagram of 14 Oct 2011 from my research journal Contracts - for process state (implemented) - for messages across the bus at each level - between processes / within conversations -Functional pub/sub - -Motivate nested VM model - - Helper subprograms that have internal communication actions should - not have those actions manifest in their interface: what would be - stateful/side-effecting subroutine calls in Scheme should retain - that RPC-like request/response flavour in our system. - - Either the states of a subprogram and its callers should remain - separate, or some powerful help should be provided by the system to - make sure they are combined in a clean, manageable, - arbitrarily-composable fashion. - - The system should make it possible to invoke a subprogram without - needing to be aware of whether and how that subprogram in turn - chooses to invoke sub-subprograms. - -Motivate roles vs Erlang-style single mailbox - - The system should make it possible for programs that would - otherwise block on some external operation to remain responsive to - their normal inputs while waiting for the external operation to - complete. - -Can represent the "natural" structure of SSH in terms of nested VMs - Whiteboard - Diagram of 14 Oct 2011 from my research journal - -Ground-level events and a ground-level VM bottom out the recursion - -Examples - HTTP Load Balancer - Bank Teller - Weaknesses - The Wart - Glitching @@ -293,11 +356,12 @@ Weaknesses - e.g. for sending SSH channel opens: is the channel type supported? querying the routing table would let us find out without explicitly sending a message - -Not just roles and sets, but *participation levels* - - participant - - observer/monitor - - "super"-observer/monitor + - Careful protocol design at all levels + - Ground events are (cons/c evt/c any/c) + - This is the set of all possible responses to sync'ing on that event! + - I've scraped by with this so far, but because sync'ing has + side-effects, I'll eventually need better names for event + requests and responsibility transfer. This got me thinking: the presence/messaging system I’ve been building looks like a hybrid between synchronous and asynchronous messaging. Is