Outline updates
This commit is contained in:
Tony Garnock-Jones
parent
913653bba9
commit
8fd2328532
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue