UBF and asynchronous communication

[Joe Armstrong]

  You are quite right! - I've been thinking about this for a while :-)

  To describe protocols I think you need a multi-layered language. I've made a little
language to do this.

  Imagine you have this:

	A -------S-------- B

  This represents a communication channel between A and B. S is the "state" of the channel.

  Now one of two things can happed:

	A message can come from A, or
	A message can come from B.

  In response to this the state of the channel changes (to say S')

  I write this as follows:

	<<M>> [A|B] x S -> S'

  This is the most general case.

  Remote procedure calls look like this:

	<<Q>> A x Si -> Sj
	<<R>> B x Sj -> Sk

  ie A sends a message <<Q> (query) and receives a reply <<R>> - since the
state Sj is "irrelevant" we can write this like this:

	<<Q>> A x Si -> <<R>> B x Sk

  If it is understood the A is a client and B a server, we can reduce this to

	<<Q>> x Si -> <<R>> x Sk

  And if the server is *stateless* (ie can accept any message in any state) we
can further simplify this to:

	<<Q>> -> <<R>

  That's the basic idea.

  My little language specifies protocols in a number of sections, like this:

---------------------- begin -----------------

Description

Send a <<getfile>> message to the serve and you'll ll get back <<thefilecontents>>
of an <<error>>

End.

Semantics

	<<getfile>> -> <<thefilecontcontents>> | <<error>>

End.

Messages

	<<getfile>> := {get, string()};
	<<thefilecontcontents>> := bin();
	<<error>> := {error, string()}
End.


Encodings

	{get, X}  = byte(1),int(4,len(X)),string(X)
	bin       = byte(2), int(4,size(self)), string(self)
	{error,X} = byte(3), int(4,len(X)), string(X)
End.

--------------- end -------------

The description section can refer to messages (things in << >> brackets)

The semantics is a finite state machine that describes the protocol

The messages section says what the messages look like as Erlang terms

The Encodings section says how Erlang terms get mapped onto the data structures that are seen
"on the wire". Rule one here says

	{get, "file23"} is encoded as the sequence of bytes

	[1,0,0,0,23,f,i,l,e]

I also support "standard" encodings.

The standard encodings are XML-RPC, my own XML transport format [*], UBF, Erlang binary,
and Erlang terms
 
<aside>

 [*] my XML transport format is like this:

	{get, "file23"} in the *standard* encoding looks like this:

	<t>
	 <e><a>get</a></e>
	 <e><s>file23</s></e>
	<t>

<t> means tuple
<e> means element
<a> means atom
<s> means string

</aside>

  I also have  a Language section - here  we can systematically change
message names and atoms from (say) English to (German) - these are the
only changes since the message names and atoms convey meaning.

Once all this is done we get the following structure

	 +--------+                            +--------+
   --->--| Driver1|------------->--------------| Driver2|----->------------
     A   +--------+             X              +--------+     B

By parameterising Driver1 and Driver2 many things are possible

	A might be English Erlang terms
	X could be XML-RPC
	B might be German Erlang terms

By changing the drivers X could change to Erlang binaries :-)

The goal is a universal multi-lingual infrastructure.

----
This is very much work in progress - the non-generic encoding rule language is
incomplete, as is the semantics language.

Spontaneous events occurring in the middle of a synchronous RPC cannot be
expressed nicely and the state machine can become messy.

On the bright side - most protocols fall into the trivial stateless pure client-server
category and are *very* easy to describe.

Also streaming protocols are easy to describe.

-----

Q: Where is all this leading? - 
A: To the panomnicom [*]



/Joe

[*] The first version of the panomnicom will appear on Planet-Lab

pan  - (Greek) all, whole, everything 
omni - (Latin) all every
com  - computer

On Tue, 23 Mar 2004, Edmund Dengler wrote:

> Hi all!
> 
> In reviewing the UBF items from Joe's website, it looks like the entire
> system is premised mostly on the basis of synchronous communication, with
> a server being the only component that can send asynchronously. Basically,
> it appears that UBF cannot talk about concurrent communication events (or
> essentially, substates) or asynchronous sends. This has a couple of items
> that impact usage from my end:
> 
> (1) We do some of our work over satellite, and with one-way trip times of
> 1 second to 4 seconds, having a communication synchronize on a response
> would generate significant throughput slowdown.
> 
> Is there the equivalent of: "type() -> EVENT", similar to "EVENT ->
> type()" for server initiated messages. Basically, messages that do not
> need to wait for a response.  Possibly "type() -> state"?
> 
> (2) If the above is feasible, has any thought been given to supporting
> concurrent operations? There are two approaches to this off the top of my
> head: (a) the use of multiple "channels" where each channel would
> implement the synchronous communication, or (b) the idea of concurrent
> states where replies can actually impact state rather than the NULL
> operator of EVENT.
> 
> Regards!
> Ed
>