Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Flux/Prototype"
(→file sync) |
|||
| Line 20: | Line 20: | ||
== file sync == | == file sync == | ||
| + | |||
| + | the file syncing in the Flux prototype is implemented on top of the asynchronous messaging. The underlying design decision is that there is no single master copy of the files/folders/projects. Instead, each participant in the Flux system (all the components that are connected to the messaging channel) can serve as a "repository" for individual files, complete projects, everything from a user, or everything in the Flux universe. To sync the content of files and projects, each participant is responsible for listening to the file sync messages, replying to file sync request messages, and to broadcast messages about changes. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | At the moment the file sync protocoll doesn't deal with conflicts and/or parallel file changes. This has to be added to the mechanism while moving the project forward. | ||
== real-time sync == | == real-time sync == | ||
Revision as of 06:21, 2 July 2014
This is a brief description of the technical details of the Flux prototype implementation.
async messaging - the foundation
The back-bone of the Flux prototype implementation is an asynchronous messaging channel. The basic idea behind this architecture is that all communication in Flux is happening via asynchronous messages. There is no RESTful API, a dedicated server that can be called, or something like that. Instead every component in Flux is connected to this messaging channel and can send and receive messages over this wire. Everything else is implemented on top of this.
The prototype implementation of the asynchronous messaging channel is based on websockets. Since this is the only way to connect to Flux, every participant can open a websocket connection to the messaging system and send and receive messages from there on. The websocket messaging server is implemented as a node.js application written in JavaScript:
Messages in the Flux prototype are in JSON notation. They can either be broadcasted to everybody in the system or send directly to a certain recipient. This is configured for each socket that is opened:
Different users are differentiated via different spaces using the room feature of the socket.io library. Therefore after connecting to the websocket server, every participant has to send a message "connectToChannel" to let that websocket connection participate in the channel for that particular user. As a result, if messages are broadcasted, they are not broadcasted "to the world", but within the channel of that user only. This is good to security as well as for keeping the traffic per socket down to the messages that are interesting for that user only.
As an additional step, the connect to the websocket itself should be secured, so that only authenticated users can successfully connect to the websocket. In addition to that the reaction to the "connectToChannel" message can be diversified by checking whether the user is allowed to enter a certain channel. By default this would be the same (the authenticated user connects to his own channel), but it could also include something like an invitation mechanism, so that users can invite and allow other users to take a look at their resources in Flux.
file sync
the file syncing in the Flux prototype is implemented on top of the asynchronous messaging. The underlying design decision is that there is no single master copy of the files/folders/projects. Instead, each participant in the Flux system (all the components that are connected to the messaging channel) can serve as a "repository" for individual files, complete projects, everything from a user, or everything in the Flux universe. To sync the content of files and projects, each participant is responsible for listening to the file sync messages, replying to file sync request messages, and to broadcast messages about changes.
At the moment the file sync protocoll doesn't deal with conflicts and/or parallel file changes. This has to be added to the mechanism while moving the project forward.