Skip to content
This repository has been archived by the owner on Jun 27, 2019. It is now read-only.

Accepted proposals for Google Summer of Code 2016

Jump to bottom
Rohit Sharma edited this page Mar 11, 2018 · 10 revisions

On this section you will find a list of the accepted proposals for Google Summer of Code 2016

Template Name

  • Student: Student name
  • Mentors: Mentors list

Description:

Deliverables:

Timeline:

Implementation:

Auto-complete

Description:

Implement Autocomplete suggestions in the Soletta Dev-App while the user is writing a FBP code. FBP is short for Flow Based Programming which allows the programmer to express business logic as a directional graph of nodes connected to type-specific ports. These suggestions are based on FBP syntax and what nodetypes the user would like to load for instance dynamic suggestion generation. For Soletta project developers it would enhance their productivity by providing easy immediate code suggestions, and for beginners in soletta development, it would encourage them to explore various other available nodetypes.

Deliverables:

  •   Live Autocomplete suggestions for existing nodetypes.

  •   Autocomplete FBP syntax.

Timeline:

  • April 22 - May 22, 2016 ( Community bonding) - I will study the code of the editor and several nodetypes, also discussing with mentors.
  • June 21, 2016 - FBP syntax based suggestions will be completed by mid-term evaluation. August 16, 2016 - Autocomplete suggestions based on nodetypes will be done by the final evaluation.
  • I can work 8 hours a day, 5 days a week during the community bonding period. During the coding period, I can assure you 48 hours a week up until 28th July after which I can give 36 hours a week until the final submission deadline.

Implementation:

Soletta Dev-App uses Ace, which is an open source web based code editor written in Javascript. Ace already has autocomplete API which uses snippets written in Javascript to generate suggestions. Ace pre-built version comes with snippets for languages ranging from c++ to verilog. Currently, this API is not used by Soletta-Dev-App. We need to enable this by embedding “ext-language_tools.js” (built in extension for ace but loaded into it by default) script into the editor page and also set editor’s options such as “enableBasicAutocompletion”, “enableSnippets” as well as “enableLiveAutocompletion” to true using Javascript in the editor’s page. Soletta-Dev-App uses “fbp_editor” as the div id for the editor in contrast to just “editor” in the default Ace build. Firstly, the idea is to write snippets for common FBP keywords which would load by default in all scenarios. I have seen that if we use a “mode-x.js” file for syntax then ace automatically looks for “snippets/x.js” file for the corresponding snippets file. We can load FBP based snippets in “fbp.js”. Secondly, dynamically generate snippets for nodetypes loaded by the user in that particular project. After snippet generation, load them into the editor’s code for autocomplete suggestions.To achieve this we need to use the nodetypes API. Currently, the API (nodetype.js) gets all the nodetypes using its getNodeTypes function. Using its return value, we can generate a snippet for each of its entry. Also, ace editor’s built-in “mode-html.js” has functions such as getPropertyCompletions and getPropertyValueCompletions which enable better formatting of autocomplete suggestions.These functions can be used in “mode-fbp.js” for the same reason.

Go bindings

Description:

I want to contribute to Soletta project by implementing one of the proposed ideas, namely “Implement Go bindings”. This implies providing a development interface accessible from the Go programming language, thus enabling Go developers out there to use the Soletta framework to build applications for their devices. With bindings for NodeJS and Python already under development, adding Go would further enhance Soletta library.

Though Go rose to popularity only in recent years, it becomes widely used in all kind of projects, ranging from web [9] to IoT [8]. Its strengths include performance, stability, being open source and supported by a large community, a design focused on effectiveness and efficiency and many available development tools. Considering these facts, I believe providing Go bindings would be a real asset for Soletta project.

Deliverables:

Below I tried to structure the contributions to Soletta project as part of GSoC program into several core steps:

  • Determination of Soletta framework parts that need to be interfaced with Go
  • Design of Go interface
  • Build system integration
  • Bindings for Soletta framework mainloop
  • Bindings for flow mechanism
  • Bindings for other parts of Soletta project API
  • Implementation of samples in Go
  • Writing tests for Go bindings
  • Writing documentation

I tried to list them in a logical, chronological order, but this is not really true for the tests implementation, as those need to be written incrementally throughout the GSoC project period.

Timeline:

Following is an approximate schedule for accomplishing important milestones. I provided an estimated end date for each task along with their expected duration. There is a long a period of time until the coding period starts (proposal selection period + community bonding period), which I plan to use to get familiar with particular Soletta framework components relevant to the project, contributing to Soletta project (there were added recently a lot issues with this purpose). I expect after this period to have a very clear understanding of how the project should be developed.

  • 22 May End of bonding period, start of GSoC program
  • 5 June API design (2 weeks)
  • 12 June Build system integration (1 week)
  • 19 June Mainloop (1 week)
  • 27 June Midterm evaluation
  • 24 July Flow (4 weeks)
  • 7 August Other components (2 weeks)
  • 14 August Samples, tests and documentation (1 week)
  • 23 August Final evaluation
  • Post GSoC Maintenance of the Go bindings

I left out 2 weeks in the timeline (one pre and one post midterm) to accommodate delays or other unpredictable events. If that won’t be the case, they will be used as additional time for project implementation.

For the GSoC program I plan to allocate at least 30 hours per week, in flexible manner. My timezone is GMT+2 (EET). I consider the time difference won’t be an issue, especially since I was always able to effectively communicate with Soletta project developers prior and during GSoC application period.

Implementation:

Approach

I have considered multiple approaches to implement Go bindings.

Swig [6]

Swig tool suite allows to specify a “glowing” interface in a “.i” file. One can write wrappers for C or C++ code that will be accessible from Go. Swig can also be used to write bindings for other programming languages, so it would have been useful if Soletta framework would have been providing all bindings (nodejs, python) using swig, however that is not the case.

Some downsides of this approach would be that there are some tricky corner cases when dealing with memory allocation and require a separate tool chain (additional build dependency).

cgo [7]

cgo comes with the Go toolchain and feels like it is built-in. It enables linking against C programming language, Go to reference C (writing extension modules for Go applications in C) and C to reference Go (e.g. create Go interface for C library). It appears to be straightforward to use, while providing all the necessary support for writing bindings.

The downsides of this approach that I found include the fact that it only interfaces with C code (not applicable for Soletta project, since it is written in C) and there is somewhat limited documentation (though I believe it is sufficient) on cgo.

In conclusion, I think that the CGo approach is more suitable to accomplish the goal of the project. To illustrate this, I prepared a Proof of Concept [2] (which I encourage to take a look at), as part of the proposal that shows the basic workflow for binding Soletta project. Though it is a minimalistic example, it works and, aside from illustrating a simple usage on how a user could develop in Go for Soletta project, it shows that cgo is a feasible approach:

C sample:

static int data;

static bool
on_timeout_cb(void *data)
{
    printf("data = %d\n", *((int *) data));
    (*((int *) data))++;
    return true;
}

int main(int argc, char **argv)
{
    sol_init();
    sol_timeout_add(1000, &on_timeout_cb, &data);
    sol_run();
    sol_shutdown();
    return 0;
}

Equivalent Go sample with same functionality:

func on_timeout_cb(data *int) int {
    println("data =", *data)
    (*data)++
    return 1
}

var data int

func main() {
    s := soletta.Soletta{}
    s.Start()

    s.AddTimeout(1000, on_timeout_cb, &data)

    s.Run()
    s.Stop()
}

Just as a note, binding sol_timeout_add is this just a demonstrative example, to test cgo features, as the function doesn’t require bindings because it has a Go equivalent (channels and select).

Design of Go interface

One goal of the project (also specified in the ideas page) is to design a Go-like interface, that is to make use of existing libraries and programming idioms over Soletta project. This require a research on which Soletta framework modules have or do not have a Go alternative, and a comparison in the cases where the Go equivalent is present. Since Soletta framework mainloop is core, it has to be wrapped in a way and the same apply for the flow mechanism, which doesn’t really have an equivalent in Go.

Ideally, the unavailable Soletta project C-API [11] from Go should be covered as much as possible. However, parts of the API, such as data structures, timeouts, etc. will not be binded, since there are Go specific features such as coroutines and channels, for example, that accomplish the same thing.

The project go-qml [21] has a similar structure to what we want to achieve, so it can be used to find ideas and approaches for achieving the goals of this proposal.

Build system integration

The Go bindings need to be built (compiled) somehow, in a way that would impact the end-user in a minimum way. I see 2 ways of accomplishing (not entirely disjunct) this: The Go bindings component gets a new entry in the current Soletta project build system (makefiles, configuration files, etc), similarly to how nodejs and Python bindings are treated. Make use of Go get command and install the bindings as a third-party package, e.g. from a git repository. One could install Soletta project package (or build from source), and then install the bindings package separately. This increases the logic separation and modularity.

Either way, Go bindings code will live in a separate directory layout according to Go practice (e.g. $GOPATH/src/go-soletta-flow). The second way is preferable, since it has minimum impact on Soletta project build system, however I think this approach may have some limitations if there would be a case where Soletta library would reference Go (which would increase the coupling).

Mainloop integration

As Caio Oliveira suggested, binding Soletta framework mainloop as is won’t have much value. So I plan to cover only the essential functionality from mainloop C API, and focus the effort on flow.

I think this can be done by directly wrapping the mainloop API in a Go interface. Some of the functions will have Go equivalents (sol_argc, sol_args_set, sol_argv, sol_timeout_add, sol_timeout_del), others (such as sol_idle_add, sol_idle_del, sol_mainloop_default_main) require passing callbacks from Go to C, which is possible using cgo. The API would be partially covered, with focus on those aspects that make more sense for a Go perspective.

Another approach is to replace (more specifically moving the mainloop implementation to Go bindings, and enabling it either via sol_mainloop_set_implemenation or sol_mainloop_source_add, or by including a separate source file like sol-mainloop-impl-posix.c) the mainloop mechanism entirely using Go channels and select statement, to provide asynchronous, event-driven programming. This approach seems more complex (since it involves C refering to Go code), and require careful examination when binding other components that inject events on the mainloop queue (e.g. flow nodes), however it allows more flexibility, should it be viable.

Flow paradigm

Binding the Soletta project flow paradigm will be core for the summer project, as they have more value for Go developers. Though there is already a library (goflow [22]) that implements a dataflow and flow-based programming, it has ”quite a minimalistic” implementation as the author states. Soletta project flow on the other hand has support for domain specific language, support for metatypes and access to existing nodes written in C.

Go bindings should cover at least the following: Loading of nodes Parsing Manually creating flows Create custom nodes A standalone container type for node interaction

In the beginning I think there should be designed a base interface which each node type will extend. There are a lot of node types [18], however there might not be the case to make individual bindings for each builtin node, as they can be loaded by name.

Other Soletta project components

It is necessary to determine which Soletta framework components are available in Go in one form or another (built-in, native libraries or third-party libraries). Those who already have an alternative in Go don’t require bindings at all, while others may require just a thin wrapping layer. Following is a list of components that I tried to identify starting from Soletta project's C API and the status of their potential Go equivalent.

Types and Data types (Arena, Buffer, List, Vector, String table etc.) are mostly built-in. Same applies for Soletta project utility functions. The Worker Thread API is provided by Go coroutines. Most MACROs are C specific and not applicable for Go language.

CoAP seems to be provided by go-coap [17] and canopus [16] HTTP is provided by Go package “net/http”. LWM2M seems to be provided by Betwixt [12] MAVLINK seems to be provided by go-mavlink [13] MQTT is provided by SurgeMQ [14] and mqtt [15] Network is provided by Go package “net”. OIC doesn’t seem to be available.

JSON is provided by Go package “encoding/json”. Message digest and Certificates are provided by Go packages “crypto” and “crypto/tls”. Logging is provided by Go package “log”.

Many Platform utilities are also provided by built-in Go packages, however they might need to be wrapped to be coupled with Soletta framework mainloop, since they use callback logic. I believe detaching them from mainloop and provide a pure Go implementation would also be viable, but requires more analysis and work.

Since a lot of Soletta framework components don’t require binding, the focus of the project will be on binding flow mechanism. If other components would be identified during the program to require binding, that will be covered in the available timeline.

Samples, tests and documentation

It is also important to provide examples on how to use the newly created go bindings. Aside from the fact that these are helpful to end-users, they also help during the development process by acting as a test suite. Due to this reason, a part of the samples will be migrated to Go code during bindings implementation.

Since Soletta project has a test suite, it would be great to have some tests for Go bindings too. The functional and tests with a higher level of abstraction would form a separate test suite (as is the case for nodejs bindings), but I think it would also be nice to have some unit tests where necessary.

I plan to use GoDoc [19] to generate documentation for Go bindings in the same way doxygen is currently used for C code. I would have used the same tool for Go to be consistent, however there doesn’t seem to be an easy or recommended way to do so.

Please note that writing tests and documentation is an ongoing process. Usually, the workflow I follow is design - implementation - testing - documentation, then proceed to next feature. In my experience, making granular, incremental steps leads to better code and fewer coding errors. So consider the entry in the timeline being “make sure there are enough samples, tests and documentation” instead of “write tests and documentation at the end of summer project”.

[1] http://monkey-project.com/

[2] https://github.com/kaspersky/soletta_gobindings_poc

[3] https://github.com/torvalds/linux/commit/ec9bed9d385fd094b20fa0809c50741710afdc74

[4] https://github.com/torvalds/linux/commit/c429df9df06af21912741d5a3848306328564262

[5] https://github.com/solettaproject/soletta/commits?author=kaspersky

[6] http://www.swig.org/Doc2.0/Go.html

[7] https://golang.org/cmd/cgo/

[8] http://gobot.io/

[9] http://thenewstack.io/a-survey-of-5-go-web-frameworks/

[10] https://github.com/monkey/monkey/commits?author=kaspersky

[11] http://solettaproject.github.io/docs/c-api/

[12] https://github.com/zubairhamed/betwixt

[13] https://github.com/ungerik/go-mavlink

[14] https://github.com/surgemq/surgemq

[15] https://github.com/jeffallen/mqtt

[16] https://github.com/zubairhamed/canopus

[17] https://github.com/dustin/go-coap

[18] http://solettaproject.github.io/docs/nodetypes/

[19] https://godoc.org/golang.org/x/tools/cmd/godoc

[20] https://github.com/trustmaster/goflow

[21] https://github.com/go-qml/qml

sol-lwm2m

  • Student: Bruno Melo [bsilva.melo at gmail dot com]
  • Mentors: Bruno Dilly, Guilherme Iscaro

Description:

Soletta project has its own implementation of the lightweight machine to machine (LWM2M) protocol. The LWM2M protocol is used to remotely control IoT devices, these include: Firmware updates, status reporting and etc. Although Soletta framework already implements the LMWM2M Server and the LWM2M Client, Soletta framework's implementation is lacking some main features, namely: an LWM2M Bootstrap Server, Message Encryption and Data Access Control.

The idea is to:

  • Add support to LWM2M Bootstrap Server on Soletta project, as specified by OMA, enhancing IoT developers' choices on how to bootstrap their machine-to-machine devices.
  • Add support to CoAP Message Encryption inside Soletta framework's implementation of LWM2M, giving IoT developers' an increase sense of security when using LWM2M through Soletta project.
  • Add support to Data Access Control, allowing a LWM2M Client to support one or more LWM2M Servers, by determining which server is authorized to perform which operation. The LWM2M specification specifies Access Control Objects to handle authorization, and they will be implemented from scratch.

Deliverables:

Deliverables include API Code, Internal Code Changes, Unit Tests, Doxygen Documentation and Sample Applications.

LWM2M Bootstrap Interface

The following operations will be implemented:

  • Bootstrap Request
  • Write
  • Delete
  • Bootstrap Finish

CoAP Message Encryption

I will integrate tinyDTLS (already used by Soletta framework's OIC implementation) for Soletta project's LWM2M implementation, supporting the following modes:

  • Pre-Shared Keys (with TLS_PSK_WITH_AES_128_CCM_8 Cipher Suite)
  • Raw Public Key Certificate (with TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 Cipher Suite)

Data Access Control

Support will be added from scratch, and I will implement the following:

  • Access Control Object
  • Access Control Object Management
    • Instantiation
    • Update
  • Authorization mechanisms on the following operations:
    • Create
    • Read
    • Observe
    • Write
    • Delete
    • Execute
    • Notify

Testing

Every feature will be unit-tested. Soletta project already has a place for tests related to its LWM2M implementation: ​ test­-lwm2m. As new features are developed, they will be added to that file as well.

Documentation

Doxygen documentation will be created during the whole development process.

Samples Applications

Current sample applications lwm2m-­server and ​lwm2m-­client will be enhanced to cover the new features, as well as a new one for lwm2m­-bs-­server will be created.

Stretch Goals (in case there is enough time)

  • X.509v3 Certificates with TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 Cipher Suite

Timeline:

During the implementation period, I intend to use around 40 hours per week for the GSoC project. Until there, during the community bonding period, besides getting to know the community itself and the tools used throughout the development process, I will be exploring more of the codebase (mainly focused on lwm2m-related parts), and also studying more about DTLS (and tinyDTLS), in order to better design the steps for CoAP Message Encryption.

Below is a proposed schedule for accomplishing some important milestones:

  • 27/05: Bootstrap Interface Pt.1
    • sol_lwm2m_bootstrap_request
    • sol_lwm2m_bootstrap_finish­
    • sol_lwm2m_bootstrap_write
  • 03/06: Bootstrap Interface Pt.2 (Final)
    • ­ sol_lwm2m_bootstrap_delete
    • ­ lwm2m-­bs-­server
    • ­ lwm2m­-client [supporting Bootstrap]
  • 10/06: Data Access Control Pt.1
    • access_control_object
    • Access Control Instantiation during Bootstrap (for each Object) and during Server Creation (for each Object Instance)
    • Authorization mechanisms for Create
  • 17/06: Data Access Control Pt.2 (Final)
    • Authorization mechanisms for Read, Observe, Write, Delete, Execute and Notify
    • Access Control Updating for Write and Delete
  • 24/06: Testing, Sample Applications and Documentation (Review Week Pt.1)
    • Thorough assurance of working unit-tests, samples and comprehensive documentation, including conformance checking with the specification.
  • 08/07: CoAP Message Encryption Pt.1
    • Definition of changes for ​sol-­lwm2m ​and draft implementation
  • 15/07: CoAP Message Encryption Pt.2
    • Pre-Shared Key security mode with Cipher Suite TLS_PSK_WITH_AES_128_CCM_8 [Work-in-Progress branch]
  • 22/07: CoAP Message Encryption Pt.3
    • Pre-Shared Key security mode with Cipher Suite TLS_PSK_WITH_AES_128_CCM_8 [Full]
  • 29/07: CoAP Message Encryption Pt.4
    • Raw Public Key security mode with Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [Full]
  • 05/08: CoAP Message Encryption Pt.5 (Final)
    • Full sol-­lwm2m ​changes implementation
  • 12/08: Bootstrap Server + CoAP Message Encryption + Data Access Control (Wrap-up)
    • Sample applications in a scenario with a lwm2m-­bs-­server, a lwm2m­-client and at least two lwm2m-servers, working with encryption and data access control
  • 15/08: Testing, Sample Applications and Documentation (Review Week Final)
    • Thorough assurance of working unit-tests, samples and comprehensive documentation, including conformance checking with the specification.

Implementation:

An API for the Bootstrap Interface will be implemented, to exchange Bootstrap Information. An example draft of the API would be:

  • sol_lwm2m_bootstrap_request
  • sol_lwm2m_bootstrap_write
  • sol_lwm2m_bootstrap_delete
  • sol_lwm2m_bootstrap_finish

And existing functions, such as ​read_security_server_obj, will be modified to include calls to the Bootstrap Interface in the ​sol_lwm2m_client_start flow.

A complete implementation of the LWM2M Security Object will be added, including the currently missing fields (Resources' values) needed by LWM2M to setup CoAP encryption through DTLS before communication take place. Internal changes in sol-lwm2m will be responsible for including the key-exchange steps in the flow, using the newly added fields as configuration parameters.

An Access Control Object will be implemented. One [incomplete] draft snippet for that implementation would be:

static const struct sol_lwm2m_object access_control_object = { 
    SOL_SET_API_VERSION(.api_version = SOL_LWM2M_OBJECT_API_VERSION, ) 
    .id = ACCESS_CONTROL_OBJ_ID, 
    .resources_count = 3, 
    .read = read_access_control_obj, 
    .write = write_access_control_obj, 
    .delete = delete_access_control_obj, 
    .create = create_access_control_obj 
};

The Access Control Object will be instantiated as part of the Bootstrap flow and the Create flow. It will be updated as part of the Write and Delete flows (the ​handle_resource() API function will be enhanced to support this update mechanism, making use of SOL_COAP_RSPCODE_UNAUTHORIZED when needed). And it will be checked for minimum access rights as part of the Read, Observe, Write, Delete and Execute flows.

Clone this wiki locally