Outline updates

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
+       Responsibility
-       Nacks
+       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
+Talk about DNS and SSH
- - 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!
+DNS structure:
- - I've scraped by with this so far, but because sync'ing has
+  - timer
-   side-effects, I'll eventually need better names for event requests
+  - udp
-   and responsibility transfer.
+  - 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
-
+ - Careful protocol design at all levels
-Not just roles and sets, but *participation levels*
+    - Ground events are (cons/c evt/c any/c)
- - participant
+    - This is the set of all possible responses to sync'ing on that event!
- - observer/monitor
+    - I've scraped by with this so far, but because sync'ing has
- - "super"-observer/monitor
+      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