Confirm
699
edits
Changes
backup
There will be many IPC protocols, and they should all be as error-free as possible by design. Having separate protocols for separate uses is a good thing, and they all shouldn't be multiplexed by hand over a shared transport layer. Further, protocol implementations should only have to check for errors as infrequently as possible; the heavy lifting should be done generically, or by code generated from high-level specifications.
== Terminology ==
'''NB''': this section is intended to provide an informal basis for the rest of this document. The remainder of the document should concretely define each of these terms.
An ''actor'' is a protocol end-point. This is something that can send and receive messages. We may have multiple actors per thread and per process. (E.g.: when a thread opens a TCP connection to mozilla.org, the socket object created my kernel is an ''actor'' (the ownership of this actor is up to the process containing the creating thread). The socket object created by the mozilla.org server is another ''actor''.
A ''message'' is the unit of communication between two actors. A message will probably consist of a ''message type'' and a ''message payload''. The ''message type'' will specify the actor the message is intended to be sent to, the protocol the message belongs to, and the types of each datum in the ''message payload''. The ''message type'' may additionally specify the location of data in the payload; e.g., large data may be transferred through shared memory, while small ones may be sent over a pipe. The ''message type'' should make it clear which actor owns each potentially-shared datum.
A ''protocol'' is a formal definition of the messages that two actors are allowed to send/receive to/from each other. ''Protocol'' semantics can be defined in many different ways, but we should be able to get away with "finite-state machine semantics." This means that each ''protocol'' ''actor'' has a "current state," and in that state, it is only allowed to send a set of messages ''SM'' and receive a set of messages ''RM''. Upon sending or receiving a particular message ''m'', the actor may transition into a new "state."
== Desiderata ==
# All messages sent from one actor to another are well-typed. That is, every datum in a message ''m'' sent by actor ''a'' has a static type, is serializable by an ''a'', is un-serializable by the actor that receives ''m'', and the ownership of the datum is explicit.
# All messages received by an actor are well-typed, in the same sense as above. ('''NB''': these goals are complementary. A misbehaving actor could send a non-well-typed message to another actor, and the receiving actor shouldn't suffer because of the non-well-typed message. "Suffer" might include security concerns, so this is important.)
# All messages sent from one actor to another adhere to the semantics of the actor's protocol. For the TCP example, this means that an actor in the "CLOSED" state can't send a "FIN" message.
# All messages received by an actor adhere to the semantics of the actor's protocol. This means that an actor doesn't have to worry about processing mal-formed messages sent by another, misbehaving actor. Like the message type-safety desideratum, this is likely to be a security concern and is thus important.
# ???
== Implementation Overview ==
For the overall design, we will follow the example of network protocol stacks. On top of the stack is the ''protocol layer'', and below it is the ''transport layer''. (Luckily, much of the transport layer for IPC seems to be provided by chromium.)
The transport layer is responsible for platform-specific code for communication and shared memory, connection establishment, identifying and routing messages to actors, and type safety of individual messages. Please refer to [http:://example.com TODO] for its specification.
We will follow the example of [http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf Sing#] for protocol specifications. Since C++ doesn't support this kind of code, and it's extremely hard to make it do so, and we may want to allow other languages (JavaScript) to implement protocol actors, we will implement protocol specifications as a domain-specific language. (We did the same thing for IDL.) The remainder of this document focuses on this protocol-specification language.
== Protocol-specification Language ==
A protocol has a ''server'' and a ''client''. Loosely speaking for IPC, the ''client'' '''MAY BE''' the process that forks the ''server'' process. Again loosely speaking, the ''server'' provides capabilities not inherent to the ''client''.
'''TODO''': this isn't a complete definition. Forking a plugin process fits it, but a chrome-local addon to content doesn't.
A protocol is specified with respect to the server; that is, messages the server is allowed to receive are exactly the messages a client is allowed to sent, and ''vice versa''.
A protocol consists of definitions of ''messages'' and specifications of ''state machine transitions''. (This ties us to state-machine semantics.) The message definitions are type declarations for the transport layer, and the state machine transitions capture the semantics of the protocol itself.
== Terminology ==
'''NB''': this section is intended to provide an informal basis for the rest of this document. The remainder of the document should concretely define each of these terms.
An ''actor'' is a protocol end-point. This is something that can send and receive messages. We may have multiple actors per thread and per process. (E.g.: when a thread opens a TCP connection to mozilla.org, the socket object created my kernel is an ''actor'' (the ownership of this actor is up to the process containing the creating thread). The socket object created by the mozilla.org server is another ''actor''.
A ''message'' is the unit of communication between two actors. A message will probably consist of a ''message type'' and a ''message payload''. The ''message type'' will specify the actor the message is intended to be sent to, the protocol the message belongs to, and the types of each datum in the ''message payload''. The ''message type'' may additionally specify the location of data in the payload; e.g., large data may be transferred through shared memory, while small ones may be sent over a pipe. The ''message type'' should make it clear which actor owns each potentially-shared datum.
A ''protocol'' is a formal definition of the messages that two actors are allowed to send/receive to/from each other. ''Protocol'' semantics can be defined in many different ways, but we should be able to get away with "finite-state machine semantics." This means that each ''protocol'' ''actor'' has a "current state," and in that state, it is only allowed to send a set of messages ''SM'' and receive a set of messages ''RM''. Upon sending or receiving a particular message ''m'', the actor may transition into a new "state."
== Desiderata ==
# All messages sent from one actor to another are well-typed. That is, every datum in a message ''m'' sent by actor ''a'' has a static type, is serializable by an ''a'', is un-serializable by the actor that receives ''m'', and the ownership of the datum is explicit.
# All messages received by an actor are well-typed, in the same sense as above. ('''NB''': these goals are complementary. A misbehaving actor could send a non-well-typed message to another actor, and the receiving actor shouldn't suffer because of the non-well-typed message. "Suffer" might include security concerns, so this is important.)
# All messages sent from one actor to another adhere to the semantics of the actor's protocol. For the TCP example, this means that an actor in the "CLOSED" state can't send a "FIN" message.
# All messages received by an actor adhere to the semantics of the actor's protocol. This means that an actor doesn't have to worry about processing mal-formed messages sent by another, misbehaving actor. Like the message type-safety desideratum, this is likely to be a security concern and is thus important.
# ???
== Implementation Overview ==
For the overall design, we will follow the example of network protocol stacks. On top of the stack is the ''protocol layer'', and below it is the ''transport layer''. (Luckily, much of the transport layer for IPC seems to be provided by chromium.)
The transport layer is responsible for platform-specific code for communication and shared memory, connection establishment, identifying and routing messages to actors, and type safety of individual messages. Please refer to [http:://example.com TODO] for its specification.
We will follow the example of [http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf Sing#] for protocol specifications. Since C++ doesn't support this kind of code, and it's extremely hard to make it do so, and we may want to allow other languages (JavaScript) to implement protocol actors, we will implement protocol specifications as a domain-specific language. (We did the same thing for IDL.) The remainder of this document focuses on this protocol-specification language.
== Protocol-specification Language ==
A protocol has a ''server'' and a ''client''. Loosely speaking for IPC, the ''client'' '''MAY BE''' the process that forks the ''server'' process. Again loosely speaking, the ''server'' provides capabilities not inherent to the ''client''.
'''TODO''': this isn't a complete definition. Forking a plugin process fits it, but a chrome-local addon to content doesn't.
A protocol is specified with respect to the server; that is, messages the server is allowed to receive are exactly the messages a client is allowed to sent, and ''vice versa''.
A protocol consists of definitions of ''messages'' and specifications of ''state machine transitions''. (This ties us to state-machine semantics.) The message definitions are type declarations for the transport layer, and the state machine transitions capture the semantics of the protocol itself.
