Future Direction of ClearSkies

[Steven Jewel]

Hello,

This is in response to the discussion on a recent commit [1].
We're looking particularly for the best direction in order to make the
project more portable. The pain point for the ruby code is mobile.

I've looked at a lot of different options, and while anything that
will compile to a staticly-linked binary will work, such as go and
haskell, C++ is probably the simplest solution.

My proposal is to translate the existing code over to C++ directly
[2] (without worrying too much about changing how it works) and then
transform it from there. For example, switching from threaded code to
event-driven, which will reduce the resource consumption, is something I
propose we wait to do until after the transformation.

The C++ core should require callbacks for things that will be OS
specific, like file change notifications. This is similar to how GnuTLS
works. The GnuTLS library is self contained, and has a callback that it
uses to call send() and recv() on sockets. (This is really convenient
for us because it lets us use GnuTLS over TCP or over uTP, and it makes
it so the core is simple.)

I haven't done a large C++ project for a while. I've heard good
things about the google C++ style guide [3], but we can adjust it for
this project as makes sense.

This is just a proposal for the future direction of the project.
I'm interested to hear feedback. I'll start work in a branch and if I
run into unexpected complications, then we might need to revisit it.

Steven

[1]: https://github.com/jewel/clearskies/commit/cb931471c003b370db1

[2]: Except for the utp and upnp code, which have decent libraries in C.

[3]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

[pedro....@gmail.com]

I think that style guide is not good. I do professional C++ programming for 10 years. Modern C++ uses exceptions and RAII to handle resources. Please see Bjarne's talks on 'going native' if you want a detailed rationale. Also is best to use C++11 features which are now supported across major compilers.

[Steven Jewel]

Thanks. I hadn't had a chance to give it more than a cursory glance.
Is there a better style guide available that takes that into account?

Steven

[Daniel Cachapa]

In my previous job I worked on a large project with a mostly C++ code base and we faced a few problems when it came time to make the code platform independent.

Most of the problems were due to differing support for C++ standards among the different compilers we had to use (mainly GCC, Microsoft and Intel).

I haven't read Google's guide, but my understanding of it was that it turns C++ into "C, but with objects". I think this is good policy for code which wants to be as portable as possible.

Also, since the library is unlikely to become very complex, I'd say we can live without the more whiz-bang C++ features if it helps with portability and makes it easier to understand the code.

Having said that, Pedro seems to be the person with the most relevant experience, so I'm not against your suggestions, just throwing in my two cents.

[pedro....@gmail.com]

Fortunately now major compilers support the C++03 standard fully plus many advantageous features of C++11, android ndk now ships with GCC 4.8, iOS with clang and vs2012 has also nice C++11 support. I know the intersection of features compatible around platforms, which we use in production daily. I can help with this and strongly advise against using 'C+' this is not justified anymore.

Do we want to go with C++ or is it easier to use Scala and ignore iOS for now? I don't have extensive Scala experience, but definitely know the pros and cons of doing a project in C++. I understand that handling libraries and dependencies is easier with a JVM solution.

On the other hand going with C++, there will be a significant work to compile all the required libraries for all platforms and maintain the respective build systems.

We started mentioning some libraries that are needed, I think it's a good idea to collect the preliminary list of them. In platforms such as android or windows we would need to compile them ourselves.

[Cameron Matheson]

On Sat, Jan 18, 2014 at 2:04 PM, <pedro....@gmail.com> wrote:

On the other hand going with C++, there will be a significant work to compile all the required libraries for all platforms and maintain the respective build systems.

That's an interesting point.  I was C++ was a reasonable choice because it would make it so much easier to get libs working everywhere (note: I only hack on C++ code very occasionally and then only on Linux).  C++ carries a lot of baggage that I would prefer to avoid if possible (like this discussion about which subset of C++ is appropriate to use for ClearSkies).

I would prefer a simpler language like Go.  As far as I can tell, gccgo would allow us to call C libraries and run on android/iphone (we would want to make sure this is the case though).

Whatever we settle on, I think it should allow for us to run the same core everywhere.  I think since ClearSkies lets the C libraries do all the heavy lifting, it doesn't even need to be a fast language (JS would even work, if it ran everywhere).

Cam

[Steven Jewel]

On 01/18/2014 02:04 PM, pedro....@gmail.com wrote:
> Fortunately now major compilers support the C++03 standard fully
> plus many advantageous features of C++11, android ndk now ships with
> GCC 4.8, iOS with clang and vs2012 has also nice C++11 support. I
> know the intersection of features compatible around platforms, which
> we use in production daily. I can help with this and strongly advise
> against using 'C+' this is not justified anymore.
>
> Do we want to go with C++ or is it easier to use Scala and ignore
> iOS for now? I don't have extensive Scala experience, but definitely
> know the pros and cons of doing a project in C++. I understand that
> handling libraries and dependencies is easier with a JVM solution.

I've been thinking about this as a possibility too. I'm not sure I'd
like to install the JVM everywhere, but it's certainly an improvement
over having to install ruby everywhere. :)

It looks like Oracle has something to run the JVM in an iOS app, so
there's at least the possibility of it working.

Some other choices are OOC or chicken scheme, any language that compiles
to C.

> On the other hand going with C++, there will be a significant work
> to compile all the required libraries for all platforms and maintain
> the respective build systems.

Regardless of the language we choose, we're going to have a very similar
amount of work compiling libraries for the platforms we need. For our
wire security we're using a TLS mode [1] that isn't widely supported.
Java doesn't support it, iOS doesn't support it, and Windows doesn't
support it. Even OpenSSL doesn't support it.

However, GnuTLS does support it and is self contained, meaning it
doesn't need to do the socket code itself. (That is how we're using it
right now.)

> We started mentioning some libraries that are needed, I think it's a
> good idea to collect the preliminary list of them. In platforms such
> as android or windows we would need to compile them ourselves.

The other library that we'd want to compile is libutp. We'd also need
libevent or something similar. I'm not sure on UPnP. The last time I
looked at it the available libraries were a mess. Debian has a
"upnp-router-control" program that has its own UPnP code that looks
pretty good, which we could extract. Finally, we need a JSON library.

Steven


[1]: It's DHE-PSK on this chart:
http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_exchange_algorithms_.28alternative_key-exchanges.29

[Pedro Larroy]

This is a good point, looks like the required ciphersuite is not supported in Java7:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

surprisingly I don't find any PSK ciphersuite listed as supported.

So far haven't find documentation about Android, the supported cipher suites should be returned by: getCipherSuites

http://developer.android.com/reference/javax/net/ssl/SSLParameters.html#setCipherSuites(java.lang.String[])

In the chart you provided I see that PolarSSL also supports it. I haven't used nor looked at both libraries, but isn't PolarSSL advertised as better an easier to understand? Should we consider this implementation as well?

Looking bad for a JVM based implementation then... 

[Steven Jewel]

On 01/19/2014 04:41 AM, Pedro Larroy wrote:
> This is a good point, looks like the required ciphersuite is not
> supported in Java7:

> surprisingly I don't find any PSK ciphersuite listed as supported.
>
> So far haven't find documentation about Android, the supported cipher
> suites should be returned by: getCipherSuites

Yes, DHE-PSK isn't very well supported. The non DHE PSK modes aren't
appropriate, since they don't have "perfect forward secrecy", which is
more important than usual for our particular use case.

Our other choice is to use SRP [1]. SRP seems to be well supported at
first glance, but in practice it's just as bad as PSK, since we need the
non-public-key-cryptography modes, like
TLS_SRP_SHA_WITH_AES_128_CBC_SHA. SRP doesn't need much entropy in the
keys, which would mean we could shorten our access codes and even use
"passwords" in the traditional sense, and has perfect forward secrecy
built in. (The only caveat is that we have to make sure to rate-limit
connection attempts.)

> In the chart you provided I see that PolarSSL also supports it. I
> haven't used nor looked at both libraries, but isn't PolarSSL advertised
> as better an easier to understand? Should we consider this
> implementation as well?

The reason we went with GnuTLS in the ruby implementation is that it's
widely available for platforms that ruby runs on, namely unix, OS X, and
Windows. That meant we'd only have to ship a DLL or so file in some
cases, but wouldn't have to compile it ourselves.

We can use a similar approach if the solution is written for the JVM,
using JNI to bind to GnuTLS or PolarSSL. That takes away a JVM
solution's biggest advantage (write once run anywhere), since we'd have
to ship a different binary for each platform, but in practice we'll
probably want to make installers anyway.

Steven

[1]: http://tools.ietf.org/html/rfc5054

[Steven Jewel]

On 01/18/2014 02:53 PM, Cameron Matheson wrote:
> That's an interesting point. I was C++ was a reasonable choice because
> it would make it so much easier to get libs working everywhere (note: I
> only hack on C++ code very occasionally and then only on Linux). C++
> carries a lot of baggage that I would prefer to avoid if possible (like
> this discussion about which subset of C++ is appropriate to use for
> ClearSkies).
>
> I would prefer a simpler language like Go. As far as I can tell, gccgo
> would allow us to call C libraries and run on android/iphone (we would
> want to make sure this is the case though).

I think golang would be a fairly reasonable choice, especially if it can
interop with C. ClearSkies seems to be the sort of "systems program"
that go was designed for.

It looks like it's possible to run go code on android with a patched go
compiler [1]. In fact, it looks like as long as you can generate a
normal .so file [2], it doesn't matter what was used to compile it.

As far as using gccgo, it sounds like it's not officially supported in
the NDK yet, but because of the .so support, that might not matter.

golang on iOS should be possible for the same reasons, but I can't find
any evidence that anyone has tried. I imagine that people interested in
clearskies at this point are mostly android users, so perhaps we should
cross this bridge when we get to it.

>
> Whatever we settle on, I think it should allow for us to run the same
> core everywhere. I think since ClearSkies lets the C libraries do all
> the heavy lifting, it doesn't even need to be a fast language (JS would
> even work, if it ran everywhere).

This is a good point. When adding a new share, most of the CPU time is
spent calculating SHA256 sums, which is going to be implemented in
native code by the crypto library. I imagine that's why you saw that it
used a lot of system resources, @capacha, especially on a rasberry pi.

The other CPU-intensive process is encrypting files while they are
transfered, but normally the Internet connection speed would be the
bottleneck.

By far most of the time spent in the program is just waiting for network
or disk I/O, so trying to eke out performance from every line of code is
probably not worthwhile.


Building on your point about javascript, we could usage a language that
can be embedded easily. Let's say lua, since that's commonly used for
this purpose, and definitely will work on all the platforms we've mentioned.

The way this would work would be a small C wrapper, let's call it
libclearskies. It would launch the lua interpreter, which would contain
the core logic of the program. We would also need to bind with our
libraries, like GnuTLS, which can be exposed in the same wrapper.

The GUI would interact with the lua program via the JSON "Control"
interface, so it can be written in whatever language is most convenient
for the platform. On android you'd use JNI to talk to libclearskies,
but on linux you could just have a small "daemon" wrapper in plain C
that does fork().

I don't have any actual experience with lua so a different embeddable
language might be better, but this approach should work for any of the
family of embeddable scripting languages.

Steven

[1]: https://github.com/eliasnaur/goandroid.

[2]:
http://stackoverflow.com/questions/5669220/ndk-how-to-use-a-generated-so-library-in-another-project

[Pedro Larroy]

I think if we want to have the current ruby implementation as a reference we should do an effort towards code clarity and encapsulation. Some functions now are a bit long and complex and reference data here and there breaking encapsulation, and with dynamic typing is not so easy to reason about that kind of (lack of) types.

Just my opinion hopefully taken constructively.

Pedro.

[Steven Jewel]

On 01/22/2014 12:53 PM, Pedro Larroy wrote:
> I think if we want to have the current ruby implementation as a
> reference we should do an effort towards code clarity and encapsulation.
> Some functions now are a bit long and complex and reference data here
> and there breaking encapsulation, and with dynamic typing is not so easy
> to reason about that kind of (lack of) types.

Yes, there is definitely lots of room for refactoring towards clarity.
A lot of the code needs work.

> Just my opinion hopefully taken constructively.

Feel free to speak your mind, I won't get offended.

Steven

[Daniel Cachapa]

If you don't mind me sharing my two cents, I would rather argue for starting the port to a more portable language now, instead of cleaning up the ruby code.

It seems to me that there was already a consensus on the necessity of a such port if this protocol is to take off, so perhaps it's better to not delay it any further.

The ruby reference works well enough now that the concept has been proven to work. Also, it can be used to test the port against during development, which should expedite the work.

There is also enthusiasm among the developers here which hopefully turns into contributions. The port need not be the work of a single person.

As long as I'm writing this, I'll further argue in favour of using C++:

- It's almost universally compilable

- It stands the best chance of having the necessary libraries available

- It seems to be the language with the best intersection of experience among the people here

Daniel Cachapa

--
You received this message because you are subscribed to the Google Groups "ClearSkies Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pedro Larroy]

I'm also in favor using C++.

I'm currently studying the best json library to use, I investigated several. The most promising given performance and code simplcity are gson and sajson.

I'm leaning towards sajson since I like the idea of a single allocation which would prevent any strange DOS attack. I think we can use with minimal changes.

To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-de...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Pedro Larroy Tovar   |    http://pedro.larroy.com/

[listas....@gmail.com]

Hi Everybody

My name is Luciano and I am following clearskies since a couple of months. If you plan to go with C++ and/or Java (for Android), I would like to help.

Regarding JSON libraries I have worked in the past with jansson (http://www.digip.org/jansson/) but is plain C, not C++. We should also consider JsonCpp (http://jsoncpp.sourceforge.net/). sajson seems to be good too but I could not find much documentation, there are some tests but none for serialization (objects -> json). gson is for Java.

Some questions.

Someone already did a list of required "library functionality", like threads, JSON, REST, sockets (UDP, TCP), uTP, file system, file system events, crypto, db, etc?

I don't have experience with native code in mobile environments, do we have some constrains like not using boost, qt or some other "heavy" C++ framework?

Regards

Luciano

Daniel Cachapa

To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "ClearSkies Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Steven Jewel]

On 01/23/2014 08:20 AM, listas....@gmail.com wrote:
> Someone already did a list of required "library functionality", like
> threads, JSON, REST, sockets (UDP, TCP), uTP, file system, file system
> events, crypto, db, etc?
> I don't have experience with native code in mobile environments, do we
> have some constrains like not using boost, qt or some other "heavy" C++
> framework?

Hi Luciano!

At this point I'm not aware of any constraints that would stop us
from using a heavy framework like QT. QT might be the perfect way to
make a simple cross-platform GUI, for example.

That being said, I haven't had a chance to look into something like
QT for the non-GUI portions of the project. If it has a consistent,
cross-platform build system then that'd be a major kickstart for the C++
version of the project.

Steven

[raul...@sent.com]

I'm supposed that it's too late to choose other language but I would use Rust instead of C++ without doubts.

http://www.infoq.com/news/2012/08/Interview-Rust
http://www.infoq.com/news/2014/01/rust09

http://www.rust-lang.org/

[Steven Jewel]

On 03/02/2014 10:28 AM, raul...@sent.com wrote:
> I'm supposed that it's too late to choose other language but I would use Rust instead of C++ without doubts.
>
> http://www.infoq.com/news/2012/08/Interview-Rust
> http://www.infoq.com/news/2014/01/rust09
>
> http://www.rust-lang.org/

Hi Raul,

It's never too late. If you'd like to start a rust porting effort, I'd
be happy to link to it from the main project so that other like-minded
people can find it and join in.

Steven

[Pedro Larroy]

Although C++11 is quite powerful and reasonably expressive, we chose to go ahead with it for portability reasons. Is it so bad compared to rust? How many projects and what experience you had with rust, can you share?

I think we should focus on the end result we want to achieve instead of language talk. I didn't chose C++ because it's my favourite language.

What do we win by having more incomplete clients in all the new cool languages?

Pedro.

--
You received this message because you are subscribed to the Google Groups "ClearSkies Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clearskies-dev+unsubscribe@googlegroups.com.

[Steven Jewel]

On 03/02/2014 11:26 AM, Pedro Larroy wrote:
> Although C++11 is quite powerful and reasonably expressive, we chose to
> go ahead with it for portability reasons. Is it so bad compared to rust?
> How many projects and what experience you had with rust, can you share?
>
> I think we should focus on the end result we want to achieve instead of
> language talk. I didn't chose C++ because it's my favourite language.
>
> What do we win by having more incomplete clients in all the new cool
> languages?

I think in a project like this there's no harm in having duplicated
effort. The people who strongly prefer another language would otherwise
not contribute at all, so it doesn't hurt the C++ effort.

Steven

P.S. I should be done with the protocol_cleanup branch within a few
more days. At that point I'm going to join in on the C++ implementation.

[Pedro Larroy]

http://jaredly.github.io/2014/03/22/rust-vs-go/index.html

Interesting article