Introducing myself and Blockie.io

[Thomas Backlund]

Hi all,

I'm very glad thanks to Söderlund and Lampa to have got in touch with the small but very active FBP community.

My name is Thomas Backlund and I'm the founder of Blockie.io together with my buddies Filippsen and Palmgren.

Blockie.io is a hosted FBP platform for back-end development, it's written in C++ and Lua.

We developed Blockie.io by the bottom-up approach, that is first developing a neat platform then applying a FBP layer on top of it,
so our take on FBP might differ some from the orthodox (if there is such a thing) way of doing things. I'm still reading The Book (2nd version), so I can't say exactly in what ways yet.

The underlying platform actually started out as a distributed indexing engine, which then turned into a distributed iSCSI (rfc3720) block storage, which we then turned into a distributed application development platform, which we then applied a FBP-layer to.

Anyway it feels great that so many are working on this and I guess it is up to us all here to help the world create their cool stuff without having to code it :)

All the best
Thomas Backlund
@ThomasBacklund

@BlockieIO
http://blockie.io
https://www.youtube.com/user/BlockieIO/
Yes, we are still crowdfunding although it is a bit slow: http://igg.me/at/BlockieIO/

[Alfredo]

Welcome, i hope you see you posting about your system because unorthodox implementations always trigger good discussion.

[Matthew Lai]

Thomas,

By "distributed" do you mean
(a) distributed processing within a single machine - multiple processes/threads, or
(b) distributed processing on a grid or cluster of machines?

My FBP work falls into the (b) area. It would be nice to find some friends/buddies in that domain :)

Yours,

Matt

[Thomas Backlund]

Thanks for the welcome! Looking forward to fruitful discussions :)

By distributed I mean both multi threaded on a single machine and also the possibility to lay off work to other machines having it being distributed and in some ways also fault tolerant.
So it makes it (a) + (b)  I guess.

I will try to put up a video later today to show this.

Your distributed buddie,
Thomas :)

[Rolf Lampa]

Yup, country men are always welcome. :)

- Welcome!

// Rolf Lampa

[Thomas Backlund]

Thanks! :)

For the interested,
I put up a couple of videos showing how we parallelize work either by using multithreading or by distributing it to other instances.

Multithreaded within the same Linux-proces https://www.youtube.com/watch?v=QhaPpzee5lk
Continuing with distributed execution spanning over machines. https://www.youtube.com/watch?v=XnScEeM9JPA

Cheers,
Thomas

[Matthew Lai]

Thomas,

Using your distributed execution graph in youtube as an example, is it possible to

(a) put the green and pink blocks into machine A, blue blocks in machine B and purple
      blocks in machine C? In other words is it possible to achieve peer-to-peer distributed
      processing using your current RESTfull architecture? If I understand your youtube
      example you are showing the MPI style (master/slave) type of distribution.

(b) connect the outport of the blue block back to the inport of the pink block? i.e. Is it
      possible to set up loop back?

Yours,

Matt

[Thomas Backlund]

Hi

Thanks for watching,

(a) A service (represented by the drawing canvas) could get instantiated on many machines.
     As soon as your IP reaches the Public Send block your IP will then end up in the Public Entry block on any
     (possibly the same) of the instances of the service having that Public Entry block, thus having it peer-to-peer distributed.
     Distributing your blocks is merely a question of putting them behind a Public Entry block and accessing them via Public Send block.

(b) Yes, loop backs are allowed.

What choices about this have you made for your system?

Cheers,
Thomas

[Matthew Lai]

Thomas,

Don't quite understand your Public Send/Public Entry concept but I trust folks who
can design/code/test in the wilderness :)

My choices? I just go with whatever works for me, like good old simple socket programming
to model the outport-inport connection. Socket works fine for both within the machine and across
machines communication.  The following FBP network has been executed regularly on 1 machine,
3 machines (1 pc + 2 Raspberry Pi boards) and 5 machines (1 pc + 4 older computers that were
collecting dust in the basement in their previous lives...). Same FBP graph for each test run, the only
difference is that user assigns different IP address to each node for each test run.

Matt

[Rolf Lampa]

On Saturday, December 21, 2013 8:45:22 PM UTC+1, Matthew Lai wrote:

>> ... Socket works fine for both within the machine and across machines communication. 

Interesting about the sockets!

One thing I wonder though - what about the very small lower level  components like in the Blockie.io examples where components deal with parts of strings or only array elements, will not Socket connections be a bit "expensive" if that's the default & only connection type between components? (I understand that it might not be a problem at all if the components "do more" with data in each component/process once the data has arrived, since the overhead cost for communication between components then will be proportionally lower).

I'm myself playing around with component design (Delphi/pascal) and next step is to look into what "transport protocol's" to support between components.

// Rolf Lampa

[Paul Tarvydas]

On 21/12/2013 4:54 PM, Rolf Lampa wrote:
> ....

> I'm myself playing around with component design (Delphi/pascal) and
> next step is to look into what "transport protocol's" to support
> between components.

Coroutines.

One input queue per component. Items in the input queues are tagged
with port id. A Scheduler coroutines (cooperative multitasking) with
all components - lets one component run, when the component "returns"
(yields control to the Scheduler), the Scheduler picks another component
to run.

If you want extra efficiency, guarantee (by convention?) that no
component ever leaves data on the stack when it yields (state can be
stored in the heap). Then, you only need one stack for the whole system.

pt

[Matthew Lai]

Rolf,

Very valid question indeed regarding the "expensive-ness" of the components performing simple/trivial work.
All my components so far do quite some work; the most trivial one is probably the cloner (IP duplication) and I
have 5 or 6 of those in my example graph. Overall performance is acceptable, whether it is real public domain
data extraction (< 90 minutes, TSX and TSX venture stock symbols) or stress testing (12 minutes, all raw html
data from hard disk).

Also, I follow the old school Unix style programming. So lots of small programs talking to one another, whether
through pipes or sockets, do not bug me at all :) For a good read on Unix programming philosophy this is a good
one, "The Art of Unix Programming' http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537

Yours,

Matt

[Thomas Backlund]

Hi,

Matthew,
Thanks, I especially remember some multithreaded debugging session sitting in my mosquito hat, that tested my patience pretty much as well :)

+Rolf,
We use ZeroMQ for socket handling together with protobuf in Blockie.

Paul,
I like your coroutines description, did you do any implementation using that?

Thomas

[Paul Tarvydas]

On 22/12/2013 11:40 AM, Thomas Backlund wrote:
> ...

> Paul,
> I like your coroutines description, did you do any implementation
> using that?

Yes, many times (7+), but mostly for clients, as yet none are open-sourced.

We did an ad-hoc coroutine scheme, using interrupts (no O/S, bare
metal). An incoming interrupt would drive the components through their
paces. One stack. In this scheme, each component carries a "busy" flag
to mark which components are "already getting cpu time" in a stack-like
manner and already haved an invocation frame somewhere on the stack ;
the busy flag prevents components from being stacked multiple times if a
feedback loop is encountered. Every component appears as a reactive
"device driver".

The one-stack guarantee comes about by convention - no component
performs any significant looping, and no component leaves local state on
the stack when finished. Interrupts that arrive while (reactive) work
is still being done, cause further stacking up to the point that a set
busy flag is encountered.

The above is just an optimized special case of coroutines, where the
"list of active components" is represented dynamically within the
stack. It could be cleaned up by having the interrupt handler wake up
the Scheduler and keeping an explicit list of ready components.

You can read my "experience" papers and slide decks at
www.visualframeworksinc.com .

One of the most vital aspects of FBP is the removal of call-return -
*every* component act/reacts as if it were an independent entity. If you
can't afford to use processes, then the coroutine method is a nice
inexpensive alternative. And, if you can't afford coroutines, then the
above one-stack method is cheaper still :-).

pt

[Matthew Lai]

Thomas,

Another dumb question: you do allow more than one input ports, correct? All
you youtube examples refer to components with a single input port only.

Matt

[Thomas Backlund]

Matt,
    Yes, correct, there could be many inports on each block.

Paul,
    You do have a lot of interesting stuff.
    What is the reason you say that removing "call/return" is so vital to FBP?
    (By this I think I understand you mean that each component only talks in one direction (out->in) and could not bubble upwards (out<-in) as we could do in Blockie.)
    Is that to not have any local state in a component to minimize the usage of resources?
    Gotta love that you implemented it on "bare-metal" without ans OS... Hall of fame for that. :)

Thomas

[Rolf Lampa]

"Fire and forget". Like so:

out->Merry Christmas!  :)

// Rolf Lampa

(nonblocking,  no need to wait for aresponse. It's entirely up to the receiver if (s)he/it calls back.  :-) )

--
You received this message because you are subscribed to a topic in the Google Groups "Flow Based Programming" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/flow-based-programming/ImEgjug6DyU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Lai]

Thomas,

May I ask what is the rationale behind the bubble upwards (out<-in) in your design?

I do have (out<-in) in my design, but only for the purpose of implementing the bounded
buffer concept as described in the FBP book. My inport returns ACK/NACK/SHUTUP
back to the sending outport; no data is ever sent back to the sending outport.

BTW, do you implement bounded buffer (max number of IPs in each outport -> inport
connection)  in blockie.io?

Yours,

Matt

[Thomas Backlund]

Hi,

Blocks could just fire and forget, but by default will expect a return IP and will pass it on upwards (possibly altering it) on a return, it's just kind of practical (we think) especially when dealing with REST services.
It also gives the possibility for some quite advanced flows to take place. The cost (except the risk of having more complex flows) is that a block must keep state, but there is no blocking of threads going on.
That takes us to bounded buffer, which is as you know not all easy to get free from deadlocks. And some kind of roof must be set otherwise the physical limit of the machine becomes the roof. We are experimenting with this still, and one approach is to recognize high levels of IP's in the network and then throttle down the rate of incoming IP's from the outside until levels has gone down, but there's no guarantee that it will.
The situation where one IP results in two IP's and there is a loop back is of course really deadly. The good news on the other hand is that since we could keep state there is the possibility to detect infinite loops without altering the actual IP.

Merry X-mas!
Thomas

[Paul Tarvydas]

On 13-12-23 05:08 AM, Thomas Backlund wrote:
> ... What is the reason you say that removing "call/return" is so
> vital to FBP?
> ...

Call/return causes implicit synchronization between components. The
caller is effectively "blocked" until the callee does a return.

Snipping this synchronization between components is FBP's secret sauce.

In my opinion, one-way sending is a "more atomic" element of software
construction than is call/return (aka RPC). You can easily build
call/return with one-way sends (one wire for "call", another return wire
for ACK), but it is much harder to build one-way sends if all you've got
is call/return, i.e. one has to build a message delivery "kernel" to
break out of a von Neumann architecture.

For example, this implicit synchronization is why people find it "hard"
to build protocol stacks (an easy task in FBP). I've never seen an
implementation of the full 7-layer OSI model, because call/return
languages make it overly difficult.

For example, call/return is the reason that epicycles, like operating
system fully preemptive processes, were invented, replete with hoary
multi-tasking "issues".

Call/return is why node.js was invented. NoFlo was, then, invented to
cure the problems created by node.js ("everything-is-a-callback" makes
it hard to get textual code correct).

Getting rid of call/return also makes it ridiculously simple to draw
meaningful diagrams of software architectures, diagrams which can be
automatically compiled to executable code.

> Gotta love that you implemented it on "bare-metal" without ans
> OS... Hall of fame for that. :)

I was getting pretty good at rolling-my-own RTOS's until we ran into a
problem which needed faster response times than could be had with
context switches.

Using FBP leads to the revelation that operating systems are really just
libraries of "reusable" code that are supposed to make computers more
accessible to programmers.

FBP allows one to snap together an operating system out of reusable and
custom components, so why bother using an O/S? :-)

pt

[John Cowan]

Paul Tarvydas scripsit:

> Call/return causes implicit synchronization between components. The
> caller is effectively "blocked" until the callee does a return.

That of course does not mean that call/return is not allowed *within*
a component.

--
John Cowan co...@ccil.org http://www.ccil.org/~cowan
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed. Still other languages are simultaneously
overdescribed and underdescribed. Welsh pertains to the third category.
--Alan King

[Paul Tarvydas]

On 13-12-31 03:40 PM, John Cowan wrote:
> Paul Tarvydas scripsit:
>
>> Call/return causes implicit synchronization between components. The
>> caller is effectively "blocked" until the callee does a return.
> That of course does not mean that call/return is not allowed *within*
> a component.
>

Correct, for leaf components :-).

Composite components (components built using other components) shouldn't
use call/return...

pt

[Paul Morrison]

"FBP's secret sauce" - yes!  Thanks, Paul - that's great!

Wishing everyone a happy, healthy and prosperous New Year!

To paraphrase Ged, hopefully 2014 will be the year when people realize that FBP is the only way to go!

All the best,

Paul M.

pt

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.