NoFlo network protocol

[bergie]

We need a transport-independent network protocol for NoFlo that would allow communication between different instances and environments of a NoFlo network, and for the NoFlo UI to communicate with a running NoFlo instance.

Transports to support would include:

• window.postMessage for talking with browser-side NoFlo running in an iframe and with Web Workers
• WebSockets for communicating between client-side and server-side NoFlo
• child_process.send for talking with Node.js child processes running NoFlo
• ZeroMQ for server-to-server communications

An additional advantage for such protocol would be that it doesn't need to be limited to NoFlo. It would allow talking with other FBP implementations, like GoFlow and PhpFlo as well.

The protocol should be atomic, with each operation sent as a separate packet.

Port-to-Port protocol

The base level of the protocol is the messaging between the output port of one component, and the input port of another.

For this we need messages that provide:

• connect (beginning of transmission)
• begingroup (start of a named group of packets)
• data (individual data packet)
• endgroup (end of a named group of packets)
• disconnect (end of transmission)

See #98 for a description of the various events.

NoFlo runtime protocol

This protocol is used for talking to a remote NoFlo runtime - whether a NoFlo instance running in a separate IFRAME, or on a external server.

Graph management

• clear (clear the current graph, if any, and prepare the environment for a fresh graph)
• getgraph (request the current graph state from the other end, received via series of addnode/addedge packets)
• addnode (add a node to the graph)
• removenode (remove node from the graph)
• renamenode (rename a node)
• addedge (add an edge to the graph)
• removeedge (remove an edge from the graph)
• addinitial (add an IIP)
• removeinitial (remove an IIP)

Component management

• getcomponents (request a list of available components)
• component (component definition including name, description, and ports. We may or may not want to send component tests and source code as part of the payload)

Network management

• start (start a NoFlo network based on the currently specified Graph)
• stop (stop the currently running NoFlo network)
• error (an uncaught error has happened in the network)

The running NoFlo network should also transmit all individual packet events using the Port-to-Port protocol with added metadata on the sender and receiver on the packet.

[bergie]

See https://github.com/noflo/noflo-runtime-iframe for a testbed of the network communications, this time using postMessage with an IFRAME

[bergie]

The new iteration of NoFlo UI is also using the protocol to talk to actual NoFlo runtimes: https://github.com/noflo/noflo-ui

[jonnor]

Hi Henri. I've been playing with a FBP implementation for microcontrollers like Arduino, with integrating with NoFlo in mind: https://github.com/jonnor/microflo (wanted a couple of more things fixed before announcing..)
It uses a binary command stream (for effective parsing) based on something like the proposed protocol to load graphs into the runtime. See https://github.com/jonnor/microflo/blob/master/microflo/commandformat.json
Currently it can only load from what is baked into the firmware image, but eventually this will happen over serial etc. - and hopefully be possible from NoFlo UI and similar.

Comments:

• I think that it should be possible to observe a remote graph, and get messages of graph changes without resorting to polling. Is that what you have in mind?
• Minor: Why not call "graph" for "clear" or "reset"?

[bergie]

@jonnor looks very promising! Are you now in Berlin or Norway? Would be fun to meet and integrate this with the UI.

As for the questions:

I think that it should be possible to observe a remote graph, and get messages of graph changes without resorting to polling. Is that what you have in mind?

Sure, already implemented in the IFRAME runtime using the "port-to-port" protocol over the network channel: https://github.com/noflo/noflo-runtime-iframe/blob/master/runtime/network.js#L129

Minor: Why not call "graph" for "clear" or "reset"?

Good point, I guess clear is better. I'll change that.

[trustmaster]

Looks good to me so far. I'm talking about the Port-to-Port protocol because a Runtime protocol is a task for a more distant future in GoFlow.

I'm not sure about supporting begingroup and endgroup because currently GoFlow makes no use of the FBP "substreams" or "trees" concepts and relies on native structs instead.

[bergie]

@trustmaster there is a bunch of components that ignore the group/tree information anyway, so I don't see that as a problem.

If GoFlow could talk the network protocol over WebSockets, then the UI could fully work with that :-)

[jonnor]

@bergie Getting together to integrate with the UI would be great! I am in Norway these days, but would like to go to Berlin soon...

[bergie]

The network protocol seems to be working fine now. We still need to write more formal documentation for it, but I'll close this issue.

[rektide]

Running near 6 weeks now. Please give us docs!!! I'm only interested in NoFlo as far as I can do things with it, and until you have docs for remote protocols, I can not do anything.

[jonnor]

@rektide I agree that docs would be nice. However, its easy to hook up NoFlo UI to a WebSocket based runtime and see the exact format of the messages described here. I know as I already did it.
Beware of issue described in noflo/noflo-ui#21 though

@bergie when implementing support in MicroFlo I found it annoying that the naming conventions for edges are different in the WebSocket protocol compare to the .json format. I ended up normalizing it internally. Any chance of unifying this or do you consider the protocol locked?

[bergie]

@jonnor that is the main reason I haven't written down the protocol docs yet, as there may be things we still want to tune.

Soon we will need some additional capabilities as well:

• Registering multiple graphs to the runtime (for subgraph support)
• Getting the source code of components, and sending modifications to them (on platforms where this makes sense)

[jonnor]

@bergie Ok, cool.
I'll try to add subgraph support in MicroFlo at the same time as we define the protocol (issue microflo/microflo#4).

I would like it also to be possible for subgraphs (or similar mechanism in the UI) to be able to use different runtimes. Usecase is hetrogenous FBP, where you have a system which may consist of clients (using NoFlo client-side), a server/host (using NoFlo node.js) and microcontrollers/sensors (using MicroFlo). I want to be able to look at my entire system as the interconnect between these different devices/roles, and then be able to drill-down/move-into a specific device/role (and thus runtime) to be able to see and change that part of the system.

[bergie]

Initial documentation for the protocol: http://noflojs.org/documentation/protocol/