[erlang-questions] Ideas for a new Erlang

[Ulf Wiger]

2008/7/22 Sven-Olof Nystr|m <svenolof@REDACTED>:
> Ulf Wiger writes:

>  >
>  > A good place to start might be the POTS control program, which was
>  > presented in the Erlang book, and also used (in a slightly different form)
>  > in the Introductory Erlang course.
>  >
>  > I used it in my "Structured Network Programming" presentation to
>  > show the consequences of different programming styles in multiway
>  > signaling:
>  >
>  > http://www.erlang.se/euc/05/1500Wiger.ppt
>  >
>  > I'm not convinced that it will be sufficient to reveal significant differences
>  > between the standard erlang style and channels, but it's a good place to
>  > start, and the code can be expanded in a number of interesting ways.
>  >
>  > BR,
>  > Ulf W
>  >
>  > (There's a working simulator to go with the program, but the OTP team
>  > would have to give permission to release it in public. I'm sure you can
>  > get your hands on it anyway.)
>
>
> Sorry about disappearing from the discussion for so long.
>
> I took a look at the POTS program in the Erlang book. It is actually
> easy to rewrite it to use neither channels nor selective receive.
>
> I also looked at the gen-server module.
>
> Detailed comments follow. (A non-selective receive is one that always
> pick the first message in the mailbox.)
>
> Sven-Olof
>
>
>
> The book's implementation of POTS only contains four receive
> expressions. Among these, only one (in the function make_call_to_B/3)
> is selective.

You should also take a look at the presentation that I referred to.

Just looking at the example in the book, you are making the same
mistake as the Nordlander thesis on OHaskell. The POTS system
also uses messages to control the switch hardware, and this control
is stateful and synchronous. Furthermore, I believe that the MD110
hardware had no way to queue requests, so the control system must
take care to issue only one request at a time.

The OHaskell example assumed that functions like start_tone()
were atomic and non-blocking - they are not.

In my presentation, I also made the number analysis asynchronous,
which may seem far-fetched in the limited POTS example, but is quite
realistic when one considers modern IP-based telephone. The
idea was to convert synchronous requests into explicit asynchronous
request-reply pairs, and having at least two such protocols that could
interleave.

A SIP signaling control system can make as much as 5-10 network-
based (or more) requests for one call, for things like billing,
admission control, location lookup, resource allocation, etc.
All conceptually synchronous,  but the SIP signaling is asynchronous.
The interleaving of all signals make a global state-event matrix
impossibly complicated, so conceptual layering is essential.

BR,
Ulf W