How RSA public key encryption works

RSA is an algorithm used by modern computers to encrypt and decrypt messages. It is an asymmetric cryptographic algorithm. Asymmetric means that there are two different keys. This is also called public key cryptography, because one of them can be given to everyone. The other key must be kept private. It is based on the fact that finding the factors of an integer is hard (the factoring problem). RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman, who first publicly described it in 1978. A user of RSA creates and then publishes the product of two large prime numbers, along with an auxiliary value, as their public key. The prime factors must be kept secret. Anyone can use the public key to encrypt a message, but with currently published methods, if the public key is large enough, only someone with knowledge of the prime factors can feasibly decode the message.

Operation

RSA involves a public key and private key. The public key can be known to everyone, it is used to encrypt messages. Messages encrypted using the public key can only be decrypted with the private key. The keys for the RSA algorithm are generated the following way:

  1. Choose two different large random prime numbers  {\displaystyle p\,} and  {\displaystyle q\,}
  2. Calculate {\displaystyle n=pq\,}
    •   {\displaystyle n\,} is the modulus for the public key and the private keys
  3. Calculate the totient: {\displaystyle \phi (n)=(p-1)(q-1)\,}.
  4. Choose an integer {\displaystyle e\,} such that 1 <  {\displaystyle e\,} < {\displaystyle \phi (n)\,}, and {\displaystyle e\,} is coprime to {\displaystyle \phi (n)\,} ie: {\displaystyle e\,} and {\displaystyle \phi (n)\,} share no factors other than 1; gcd(  {\displaystyle e\,}, {\displaystyle \phi (n)\,}) = 1.
    •   {\displaystyle e\,} is released as the public key exponent
  5. Compute {\displaystyle d\,} to satisfy the congruence relation {\displaystyle de\equiv 1{\pmod {\phi (n)}}\,} ie: {\displaystyle de=1+k\phi (n)\,} for some integer  {\displaystyle k\,}.
    •   {\displaystyle d\,} is kept as the private key exponent

Notes on the above steps:

  • Step 1: Numbers can be probabilistically tested for primality.
  • Step 2: changed in PKCS#1 v2.0 to {\displaystyle \lambda (n)={\rm {lcm}}(p-1,q-1)\,} instead of  {\displaystyle \phi (n)=(p-1)(q-1)\,}.
  • Step 3: A popular choice for the public exponents is  {\displaystyle e\,} = 216 + 1 = 65537. Some applications choose smaller values such as {\displaystyle e\,} = 3, 5, or 35 instead. This is done to make encryption and signature verification faster on small devices like smart cards but small public exponents may lead to greater security risks.
  • Steps 4 and 5 can be performed with the extended Euclidean algorithm; see modular arithmetic.

The public key is made of the modulus  {\displaystyle n\,} and the public (or encryption) exponent  {\displaystyle e\,}.
The private key is made of the modulus  {\displaystyle n\,} and the private (or decryption) exponent  {\displaystyle d\,} which must be kept secret.

  • For efficiency a different form of the private key can be stored:
    •   {\displaystyle p\,} and  {\displaystyle q\,}: the primes from the key generation,
    •   {\displaystyle d\mod (p-1)\,} and {\displaystyle d\mod (q-1)\,}: often called dmp1 and dmq1.
    •   {\displaystyle q^{-1}\mod (p)\,}: often called iqmp
  • All parts of the private key must be kept secret in this form.  {\displaystyle p\,} and {\displaystyle q\,} are sensitive since they are the factors of  {\displaystyle n\,}, and allow computation of {\displaystyle d\,} given  {\displaystyle e\,}. If  {\displaystyle p\,} and  {\displaystyle q\,} are not stored in this form of the private key then they are securely deleted along with other intermediate values from key generation.
  • Although this form allows faster decryption and signing by using the Chinese Remainder Theorem (CRT) it is considerably less secure since it enables side channel attacks. This is a particular problem if implemented on smart cards, which benefit most from the improved efficiency. (Start with {\displaystyle y=x^{e}{\pmod {n}}} and let the card decrypt that. So it computes  {\displaystyle y^{d}{\pmod {p}}} or  {\displaystyle y^{d}{\pmod {q}}} whose results give some value  {\displaystyle z}. Now, induce an error in one of the computations. Then  {\displaystyle \gcd(z-x,n)} will reveal  {\displaystyle p} or q.)

Encrypting messages

Alice gives her public key (  {\displaystyle n\,} {\displaystyle e\,}) to Bob and keeps her private key secret. Bob wants to send message M to Alice.

First he turns M into a number  m smaller than  n by using an agreed-upon reversible protocol known as a padding scheme. He then computes the ciphertext {\displaystyle c\,} corresponding to:

  {\displaystyle c=m^{e}\mod {n}}

This can be done quickly using the method of exponentiation by squaring. Bob then sends {\displaystyle c\,} to Alice.

Decrypting messages

Alice can recover  {\displaystyle m\,} from  {\displaystyle c\,} by using her private key  {\displaystyle d\,} in the following procedure:

  {\displaystyle m=c^{d}\mod {n}}

Given  {\displaystyle m\,}, she can recover the original message M.

The decryption procedure works because first

  {\displaystyle c^{d}\equiv (m^{e})^{d}\equiv m^{ed}{\pmod {n}}}.

Now, since

  {\displaystyle ed\equiv 1{\pmod {p-1}}\,} and
  {\displaystyle ed\equiv 1{\pmod {q-1}}\,}

Fermat’s little theorem yields

  {\displaystyle m^{ed}\equiv m{\pmod {p}}} and
  {\displaystyle m^{ed}\equiv m{\pmod {q}}}.

Since  {\displaystyle p\,} and  {\displaystyle q\,} are distinct prime numbers, applying the Chinese remainder theorem to these two congruences yields

{\displaystyle m^{ed}\equiv m{\pmod {pq}}}.

Thus,

{\displaystyle c^{d}\equiv m{\pmod {n}}}.

A working example

Here is an example of RSA encryption and decryption. The parameters used here are artificially small, but you can also use OpenSSL to generate and examine a real keypair.

  1. Choose two random prime numbers
  2.  :  {\displaystyle p=61} and  {\displaystyle q=53}
  3. Compute  {\displaystyle n=pq\,}
  4.  :  {\displaystyle n=61*53=3233}
  5. Compute the totient  {\displaystyle \phi (n)=(p-1)(q-1)\,}
  6.  : {\displaystyle \phi (n)=(61-1)(53-1)=3120}
  7. Choose  {\displaystyle e>1} coprime to 3120
  8.  :  {\displaystyle e=17}
  9. Choose  {\displaystyle d\,} to satisfy {\displaystyle de\equiv 1{\pmod {\phi (n)}}\,}
  10.  :  {\displaystyle d=2753}
  11.  :  {\displaystyle 17*2753=46801=1+15*3120}.

The public key is (  {\displaystyle n=3233}, {\displaystyle e=17}). For a padded message  {\displaystyle m\,} the encryption function is:

  {\displaystyle c=m^{e}\mod {n}=m^{17}\mod 3233\,}.

The private key is (  {\displaystyle n=3233} {\displaystyle d=2753}). The decryption function is:

  {\displaystyle m=c^{d}\mod {n}=c^{2753}\mod 3233\,}.

For example, to encrypt  {\displaystyle m=123}, we calculate

  {\displaystyle c=123^{17}\mod 3233=855}

To decrypt  {\displaystyle c=855}, we calculate

  {\displaystyle m=855^{2753}\mod 3233=123}.

Both of these calculations can be computed efficiently using the square-and-multiply algorithm for modular exponentiation.

Padding schemes

When used in practice, RSA must be combined with some form of padding scheme, so that no values of M result in insecure ciphertexts. RSA used without padding may have some problems:

  • The values m = 0 or m = 1 always produce ciphertexts equal to 0 or 1 respectively, due to the properties of exponentiation.
  • When encrypting with small encryption exponents (e.g., e = 3) and small values of the m, the (non-modular) result of m e {\displaystyle m^{e}} {\displaystyle m^{e}} may be strictly less than the modulus n. In this case, ciphertexts may be easily decrypted by taking the eth root of the ciphertext with no regard to the modulus.
  • RSA encryption is a deterministic encryption algorithm. It has no random component. Therefore, an attacker can successfully launch a chosen plaintext attack against the cryptosystem. They can make a dictionary by encrypting likely plaintexts under the public key, and storing the resulting ciphertexts. The attacker can then observe the communication channel. As soon as they see ciphertexts that match the ones in their dictionary, the attackers can then use this dictionary in order to learn the content of the message.

In practice, the first two problems can arise when short ASCII messages are sent. In such messages, m might be the concatenation of one or more ASCII-encoded character(s). A message consisting of a single ASCII NUL character (whose numeric value is 0) would be encoded as m = 0, which produces a ciphertext of 0 no matter which values of e and N are used. Likewise, a single ASCII SOH (whose numeric value is 1) would always produce a ciphertext of 1. For systems which conventionally use small values of e, such as 3, all single character ASCII messages encoded using this scheme would be insecure, since the largest m would have a value of 255, and 2553 is less than any reasonable modulus. Such plaintexts could be recovered by simply taking the cube root of the ciphertext.

To avoid these problems, practical RSA implementations typically embed some form of structured, randomized padding into the value m before encrypting it. This padding ensures that m does not fall into the range of insecure plaintexts, and that a given probe, once padded, will encrypt to one of a large number of different possible ciphertexts. The latter property can increase the cost of a dictionary attack beyond the capabilities of a reasonable attacker.

Standards such as PKCS have been carefully designed to securely pad messages prior to RSA encryption. Because these schemes pad the plaintext m with some number of additional bits, the size of the un-padded message M must be somewhat smaller. RSA padding schemes must be carefully designed so as to prevent sophisticated attacks. This may be made easier by a predictable message structure. Early versions of the PKCS standard used ad-hoc constructions, which were later found vulnerable to a practical adaptive chosen ciphertext attack. Modern constructions use secure techniques such as Optimal Asymmetric Encryption Padding (OAEP) to protect messages while preventing these attacks. The PKCS standard also has processing schemes designed to provide additional security for RSA signatures, e.g., the Probabilistic Signature Scheme for RSA (RSA-PSS).

Signing messages

Suppose Alice uses Bob’s public key to send him an encrypted message. In the message, she can claim to be Alice but Bob has no way of verifying that the message was actually from Alice since anyone can use Bob’s public key to send him encrypted messages. So, in order to verify the origin of a messages, RSA can also be used to sign a message.

Suppose Alice wishes to send a signed message to Bob. She produces a hash value of the message, raises it to the power of d mod n (just like when decrypting a message), and attaches it as a “signature” to the message. When Bob receives the signed message, he raises the signature to the power of e mod n (just like encrypting a message), and compares the resulting hash value with the message’s actual hash value. If the two agree, he knows that the author of the message was in possession of Alice’s secret key, and that the message has not been tampered with since.

Note that secure padding schemes such as RSA-PSS are as essential for the security of message signing as they are for message encryption, and that the same key should never be used for both encryption and signing purposes.

Why Rails 4 Live Streaming is a big deal

TLDR: Rails Live Streaming allows Rails to compete with Node.js in the streaming arena. Streaming requires application servers to support either multi-threaded or evented I/O. Most Ruby application servers are not up for the job. Phusion Passenger Enterprise 4.0 (a Ruby app server) is to become hybrid multi-processed, multi-threaded and evented. This allows seamless support for streaming, provides excellent backwards compatibility, and allows future support for more use cases than streaming alone.

Several days ago Rails introduced Live Streaming: the ability to send partial responses to the client immediately. This is a big deal because it opens up a huge number of use cases that Rails simply wasn’t suitable for. Rails was and still is an excellent choice for “traditional” web apps where the user sends a request and expects a full response back. It was a bad choice for anything that works with response streams, for example:

  • Progress responses that continuously inform the user about the progress. Imagine a web application that performs heavy calculations that can take several minutes. Before Live Streaming, you had to split this system up into multiple pages that must respond immediately. The main page would offload the actual work into a background worker, and return a response informing the user that the work is now in progress. The user must poll a status page at a regular interval to lookup the progress of the work. With Live Streaming, you can not only simplify the code by streaming progress information in a single request, but also push progress information to the user much more quickly and without polling:
    def big_work
      work = WorkModel.new
      while !work.done?
        work.do_some_calculations
        response.stream.write "Progress: #{work.progress}%\n"
      end
      response.stream.close
    end
    
  • Chat servers. Or, more generally, web apps that involve a large number of mostly idle but persistent connections. Until today this has largely been the domain of evented systems such as Node.js and Erlang.

And as Aaron Patterson has already explained, this feature is different from Rails 3.2’s template streaming.

Just “possible” is not enough

The same functionality was actually already technically possible in Ruby. According to the Rack spec, Rack app objects must return a tuple:

[status_code, headers, body]

Here, body must respond to the each method. You can implement live streaming by yourself, with raw Rack, by returning a body object that yields partial responses in its each method.

class StreamingBody
  def each
    work = WorkModel.new
    while !work.done?
      work.do_some_calculations
      yield "Progress: #{work.progress}%\n"
    end
  end
end

Notice that the syntax is nearly identical to the Rails controller example code. With this, it is possible to implement anything.

However streaming in Ruby has never caught a lot of traction compared to systems such as Node.js. The latter is much more popular for these kind of use cases. I believe this inequality in populairty is caused by a few things:

  1. Awareness. Not everybody knew this was possible in Ruby. Indeed, it is not widely documented.
  2. Ease and support. Some realize this is possible, but chose not to use Ruby because many frameworks do not provide easy support for streaming. It was possible to stream responses in pre-4.0 Rails but the framework code generally does not take streaming into account, so if you try to do anything fancy you run the risk of breaking things.

With Live Streaming, streaming is now easy to use as well as officially supported.

Can Rails compete with Node.js?

Node.js is gaining more and more momentum nowadays. As I see it there are several reasons for this:

  1. Love for JavaScript. Some developers prefer JavaScript over Ruby, for whatever reasons. Some like the idea of using the same language for both frontend and backend (although whether code can be easily shared between frontend and backend remains a controversial topic among developers). Others like the V8 engine for its speed. Indeed, V8 is a very well-optimized engine, much more so than Ruby 1.9’s YARV engine.
  2. Excellent support for high I/O concurrency use cases. Node.js is an evented I/O system, and evented systems can handle a massive amount of concurrent connections. All libraries in the Node.js ecosystem are designed for evented use cases, because there’s no other choice. In other languages you have to specifically look for evented libraries, so the signal-to-noise ratio is much lower.

I have to be careful here: the phrases “high I/O concurrency” and “massive ammount of concurrent connections” deserve more explanation because it’s easy to confuse them with “uber fast” or “massively scalable”. That is not what I meant. What I meant is, a single Node.js process is capable of handling a lot of client sockets, assuming that any work you perform does not saturate memory, CPU or bandwidth. In contrast, Ruby systems traditionally could only handle 1 concurrent request per process, even you don’t do much work inside a request. We call this a multi-process I/O model because the amount of concurrent users (I/O) the system can handle scales only with the number of processes.

In traditional web apps that send back full responses, this is not a problem because the web server queues all requests, the processes respond as quickly as possible (usually saturating the CPU) and the web server buffers all responses and relieves the processes immediately. In streaming use cases, you have long-running requests so the aforementioned mechanism of letting the web server buffer responses is simply not going to work. You need more I/O concurrency: either you must have more processes, or processes must be able to handle more than 1 request simultaneously. Node.js processes can effectively handle an unlimited number of requests simultaneously, when not considering any constraints posed by CPU, memory or bandwidth.

Node.js is more than HTTP. It allows arbitrary networking with TCP and UDP. Rails is pretty much only for HTTP and even support for WebSockets is dubious, even in raw Rack. It cannot (and I believe, should not) compete with Node.js on everything, but still… Now suddenly, Rails can compete with Node.js for a large number of use cases.

Two sides of the coin

Reality is actually a bit more complicated than this. Although Rails can handle streaming responses now, not all Ruby application servers can. Ilya Grigorik described this problem in his article Rails Performance Needs an Overhaul and criticized Phusion Passenger, Mongrel and Unicorn for being purely multi-process, and thus not able to support high concurrency I/O use cases. (Side note: I believe the article’s title was poorly chosen; it criticizes I/O concurrency support, not performance.)

Mongrel’s current maintenance status appears to be in limbo. Unicorn is well-maintained, but its author Eric Wong has explicitly stated in his philosophy that Unicorn is to remain a purely multi-processed application server, with no intention to ever become multithreaded or evented. Unicorn is explicitly designed to handle fast responses only (so no streaming responses).

At the time Ilya Grigorik’s article was written, Thin was the only application server that was able to support high I/O concurrency use cases. Built on EventMachine, Thin is evented, just like Node.js. Since then, another evented application server called Goliath has appeared, also built on EventMachine. However, evented servers require evented application code, and Rails is clearly not evented.

There have been attempts to make serial-looking code evented through the use of Ruby 1.9 fibers, e.g. through the em-synchrony gem, but in my opinion fibers cause more problems than they solve. Ruby 1.8’s green threading model was essentially already like fibers: there was only one OS thread, and the Ruby green thread scheduler switches context upon encountering a blocking I/O operation. Fibers also operate within a single OS thread, but you can only context switch with explicit calls. In other words, you have to go through each and every blocking I/O operation you perform and insert fiber context switching logic, which Ruby 1.8 already did for you. Worse, fibers give the illusion of thread safetiness, while in reality you can run into the same concurrency problems as with threading. But this time, you cannot easily apply locks to prevent unwanted context switching. Unless the entire ecosystem is designed around fibers, I believe evented servers + fibers only remains useful for a small number of use cases where you have tight control over the application code environment.

There is another way to support high I/O concurrency though: multi-threading, with 1 thread per connection. Multi-threaded systems generally do not support as much concurrent I/O as evented system, but are still quite formidable. Multi-threaded systems are limited by things such as the thread stack size, the available virtual memory address space and the quality of the kernel scheduler. But with the right tweaking they can approach the scalability of evented systems.

And so this leaves multithreaded servers as the only serious options for handling streaming support in Rails apps. It’s very easy to make Rails and most other apps work on them. Puma has recently appeared as a server in this category. Like most other Ruby application servers, you have to start Puma at least once for every web app, and each Puma instance is to be attached to a frontend web server in a reverse proxy setup. Because Ruby 1.9 has a Global Interpreter Lock, you should start more than 1 Puma process if you want to take advantage of multiple cores. Or you can use Rubinius, which does not have a Global Interpreter Lock.

And what about Phusion Passenger?

Towards a hybrid multi-processed, multi-threaded and evented application server

To recap, each I/O model – multi-process, multi-threaded, evented – has its own pros and drawbacks:

  • Multi-process
    • Pros:
      • Excellent application compatibility.
      • Lack of threading avoids concurrency bugs (e.g. race conditions) created by threading.
      • Simple and easy to understand. If one process crashes, the others are not affected.
      • Can utilize multiple cores.
    • Cons:
      • Supports very low I/O concurrency.
      • Uses a lot of memory.
  • Multi-threaded
    • Considerations:
      • Not as compatible as multi-process, although still quite good. Many libraries and frameworks support threaded environments these days. In web apps, it’s generally not too hard to make your own code thread-safe because web apps tend to be inherently embarrassingly parallel.
      • Can normally utilize multiple cores in a single process, but not in MRI Ruby. You can get around this by using JRuby or Rubinius.
    • Pros:
      • Supports high I/O concurrency.
      • Threads use less memory than processes.
    • Cons:
      • If a thread crashes, the entire process goes down.
      • Good luck debugging concurrency bugs.
  • Evented
    • Pros:
      • Extremely high I/O concurrency.
      • Uses even less memory than threads.
    • Cons:
      • Bad application compatibility. Most libraries are not designed for evented systems at all. Your application itself has to be aware of events for this to work properly.
      • If your app/libraries are evented, then you can still run into concurrency bugs like race conditions. It’s easier to avoid them in an evented system than in a threaded system, but when they do occur they are very difficult to debug.
      • Cannot utilize multiple cores in a single process.

As mentioned before, Phusion Passenger is currently a purely multi-processed application server. If we want to change its I/O model, which one should we choose? We believe the best answer is: all of them. We can give users a choice, and let them chose – on a per-application basis – which I/O model they want.

Phusion Passenger Enterprise 4.x (which we introduced earlier) is to become a hybrid multi-processed, multi-threaded and evented application server. You can choose with a single configuration option whether you want to stay with the traditional multi-processed I/O model, whether you want multiple threads in a single process, or whether you want processes to be evented. In the latter two cases, you even control how many processes you want, in order to take advantage of multiple cores and for resistance against crashes. We believe a combination of processes and threads/events are best.

Being a hybrid server with configurable I/O model allows Phusion Passenger to support more than just streaming. Suddenly, the possibilities become endless. We could for example support arbitrary TCP protocols in the future with no limits on traffic workloads.

phusion

 

Code has just landed in the Phusion Passenger Enterprise 4.0 branch to support multithreading. Note that the current Phusion Passenger Enterprise release is of the 3.0.x series and does not support this yet. As you can see in our roadmap, Phusion Passenger Enterprise 4.0 beta will follow 3.0.x very soon.

Where is Java used in Real World?

If you are a beginner and just started learning Java, you might be thinking where exactly Java is used? You don’t see many games written in Java except Minecraft, desktop tools like Adobe Acrobat, Microsoft Office are not written in Java, neither is your operating systems like Linux or Windows, so where exactly people use Java? Does it have any real-world application or not? Well, you are not alone, many programmers ask this question before starting with Java, or after picking Java is one of the programming language of choice at graduate level. By the way, you can get a clue of where Java is used by installing Java at your desktop, Oracle says more than 3 billion devices run Java, that’s huge number, isn’t it? Most major companies use Java in one way or other. Many server side applications are written in Java to process tens of millions of requests per day, high frequency trading applications are also written in Java e.g. LMAX trading applications, which is built over their path breaking inter-thread communication library, Disruptor. In this article, we will see more precisely, what kind of projects are done in Java, which domain or sector Java is dominating and where exactly Java is useful in real-world?

Real World Java Applications

There are many places where Java is used in real world, starting from commercial e-commerce website to android apps, from scientific application to financial applications like electronic trading systems, from games like Minecraft to desktop applications like Eclipse, Netbeans and IntelliJ, from open source library to J2ME apps etc. Let’s see each of them in more detail.

1) Android Apps
If you want to see where Java is used, you are not too far away. Open your Android phone and any app, they are actually written in Java programming language, with Google’s Android API, which is similar to JDK. Couple of years back Android has provided much needed boost and today many Java programmer are Android App developer. By the way android uses different JVM and different packaging, but code is still written in Java.

2) Server Apps at Financial Services Industry
Java is very big in Financial Services. Lots of global Investment banks like Goldman Sachs, Citigroup, Barclays, Standard Charted and other banks use Java for writing front and back office electronic trading system, writing settlement and confirmation systems, data processing projects and several others. Java is mostly used to write server side application, mostly without any front end, which receives data form one server (upstream), process it and sends it other process (downstream). Java Swing was also popular for creating thick client GUIs for traders, but now C# is quickly gaining market share on that space and Swing is out of its breath.

3) Java Web applications
Java is also big on E commerce and web application space. You have a lot of  RESTfull services being created using Spring MVC, Struts 2.0 and similar frameworks. Even simple Servlet, JSP and Struts based web applications are quite popular on various government projects. Many of government, healthcare, insurance, education, defense and several other department have their web application built in Java.

Real world application of Java

4) Software Tools
Many useful software and development tools are written and developed in Java e.g. Eclipse, InetelliJ Idea and Netbans IDE. I think they are also most used desktop applications written in Java. Though there was time when Swing was very popular to write thick client, mostly in financial service sector and Investment banks. Now days, Java FX is gaining popularity but still it is not a replacement of Swing and C# has almost replaced Swing in Finance domain.

5) Trading Application
Third party trading application, which is also part of bigger financial services industry, also use Java. Popular trading application like Murex, which is used in many banks for front to bank connectivity, is also written in Java.

6) J2ME Apps
Though advent of iOS and Android almost killed J2ME market, but still there is large market of low end Nokia and Samsung handset which uses J2ME. There was time when almost all games, application, which is available in Android are written using MIDP and CLDC, part of J2ME platform. J2ME is still popular on products like Blu-ray, Cards, Set top boxes etc. One of the reason of WhatsApp being so popular is because it is also available in J2ME for all those Nokia handset which is still quite big.

7) Embedded Space
Java is also big in the embedded space. It shows how capable the platform is, you only need 130 KB to be able to use Java technology (on a smart card or sensor). Originally Java was designed for embedded devices. In fact, this is the one area, which was part of Java’s initial campaign of “write once, run anywhere” and looks like it is paying up now.

8) Big Data technologies
Hadoop and other big data technologies are also using Java in one way or other e.g. Apache’s Java-based HBase and Accumulo (open source), and  ElasticSearch as well. By the Java is not dominating this space, as there are technologies like MongoDB which is written in C++. Java has potential to get major share on this growing space if Hadoop or ElasticSearch goes big.

9) High Frequency Trading Space
Java platform has improved its performance characteristics a lot and with modern JITs, its capable of delivering performance at C++ level. Due to this reason, Java is also popular on writing high performance systems, because Though performance is little less compared to native language, but you can compromise safety, portability and maintainability for more speed and it only takes one inexperienced C++ programmer to make an application slow and unreliable.

10) Scientific Applications
Nowadays Java is often a default choice for scientific applications, including natural language processing. Main reason of this is because Java is more safe, portable, maintainable and comes with better high-level concurrency tools than C++ or any other language.

In 1990s Java was quite big on Internet due to Applet, but over the years, Applet’s lost its popularity, mainly due to various security issues on Applet’s sand boxing model. Today desktop Java and Applets is almost dead. Java is by default Software industries darling application development language, and given its heavy usage in financial services industry, Investment banks and E-commerce web application space, any one learning Java has bright future ahead of him. Java 8 has only reinforced the belief that Java will continuing dominating software development space for years to come.

Cron Jobs and Rails

Cron

If you’re reading this article, it’s probably because you’ve heard of cron jobs, cron tasks, or crontab. Cron is a piece of software written for *nix-type operating systems to help with the scheduling of recurring tasks. You may want to use cron to schedule certain recurring actions in your Rails application, such as checking each day for expired accounts or clearing out expired sessions from your database.

It’s pretty easy to start working with cron jobs. You can start editing your cron tasks using the crontab command:

1
crontab -e

This will open up a text file in your terminal’s default editor (probably vim or nano). You can change the editor that is used by prefixing the crontab command with an adjustment to the EDITOR variable:

1
EDITOR=nano crontab -e

Remember that your scheduled tasks will be run as the user that you use when you invoke crontab.

Once you’re in the editor, you can start creating and editing cron tasks. To schedule a task, you need to define when the task will run, then define the command to trigger that task. The scheduling syntax has five parts, separated by spaces (diagram taken from drupal.org):

1
2
3
4
5
6
7
# +---------------- minute (0 - 59)
# |  +------------- hour (0 - 23)
# |  |  +---------- day of month (1 - 31)
# |  |  |  +------- month (1 - 12)
# |  |  |  |  +---- day of week (0 - 6) (Sunday=0)
# |  |  |  |  |
  *  *  *  *  *  command to be executed

The parts represent, in this order, the minute(s), hour(s), day(s) of the month, month(s), and day(s) of the week to run the command. You can use the asterisk (*) to represent every unit of the part in question. So using * * * * * schedules your task to run every minute of every hour on every day of every month and on every day of the week. In addition to the asterisk, you can use comma-delimited integers and names of the week. You can also replace the 5 parts with a single predefined schedule, as explained in the wikipedia article on Cron. Once you have your schedule defined, you can follow it with any valid bash command:

1
2
3
4
5
# Every day at midnight and noon, quiely retrieve index.html from example.com, # using wget:
0 0,12 * * * /usr/bin/wget -O -q -t 1 http://example.com/index.html

# Same task, but just once every day
@daily /usr/bin/wget -O -q -t 1 http://example.com/index.html

Running Rails Application Code via Cron

It can be useful to run system and server tasks with cron, but a lot of times you’ll need to run Rails application code on a schedule. You can do this the hard way and set up a controller action (e.g. CronJobsController#some_task) that triggers application code to run, then set up a cron task to send a GET request to that action (e.g. /usr/bin/wget -O -q - -t 1 http://example.com/cron_jobs/some_task), or you can do it the easy way and run the code directly via cron. Rails has runners and rake tasks to facilitate this:

Rake Tasks from Cron

To run an existing rake task, you can change your directory to your application root, then call the rake task:

1
0 0 * * * cd /my/app/root && /path/to/bundle exec rake some_task

You can find the path to your bundle executable by typing which bundle from within your application’s root folder.

There’s no need to limit your rake tasks to ones that are already available via Rails or whatever framework and gems you happen to be using. You can write your own rake tasks and use those in your cron jobs as well. You can find more information about how to write your own rake tasks in the Rails Guides.

Runners

Another way to run code in your Rails app directly from cron is by using Rails runners. To execute rails code using rails runner, all you have to do is call rails runner "ruby code":

1
0 * * * * cd /my/app/root && /path/to/bundle exec rails runner -e production "Model.long_running_method"

The -e production sets the environment to “production”, and can be altered as needed. The Model.long_running_method portion represents a class method that can be called from within your Rails application. Using rails runner to run the code loads up your application into memory first, then evaluates the ruby code in the Rails environment. When the task completes, the runner exits.

Debugging Custom Code

To debug a runner or a custom rake task, you can print to STDOUT from within your code (using puts or similar methods). Within crontab, make sure to set the MAILTO variable to your email address so that you’ll receive that output.

1
2
MAILTO=email@example.com
* * * * * /usr/bin/some_command

As long as the server is set up properly to send outgoing email, you’ll get emailed the output.

The Whenever Gem

One difficulty with using cron is that it is awkward to maintain and store your cron jobs. The syntax can be cumbersome to beginners as well, and it’s easy to make mistakes in setting up your schedules and your executables’ paths. One way to overcome these difficulties is to use the whenever gem. Just add gem 'whenever', require: false to your Gemfile and run bundle install. Then within your application’s root directory, run the following command:

1
bundle exec wheneverize

This will add a schedule file to your config folder (config/schedule.rb). This file is where you set up your scheduled tasks. You can use regular cron scheduling, or you can use a more idiomatic DSL for scheduling. The following examples are take from the gem’s README.md:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
every 3.hours do
  runner "MyModel.some_process"
  rake "my:rake:task"
  command "/usr/bin/my_great_command"
end

every 1.day, :at => '4:30 am' do
  runner "MyModel.task_to_run_at_four_thirty_in_the_morning"
end

every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot
  runner "SomeModel.ladeeda"
end

every :sunday, :at => '12pm' do # Use any day of the week or :weekend, :weekday
  runner "Task.do_something_great"
end

every '0 0 27-31 * *' do
  command "echo 'you can use raw cron syntax too'"
end

# run this task only on servers with the :app role in Capistrano
# see Capistrano roles section below
every :day, :at => '12:20am', :roles => [:app] do
  rake "app_server:task"
end

Once you’ve set up your scheduled tasks in config/schedule.rb, you still need to apply them to your crontab. From your terminal, use the whenever command to update your crontab:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Change to your application's directory.
cd /my/app

# View config/schedule.rb converted to cron syntax
bundle exec whenever

# Update crontab
bundle exec whenever -i

# Overwrite the whole crontab (be careful with this one!)
bundle exec whenever -w

# See all the options for the whenever command
bundle exec whenever -h

There is a capistrano extension for whenever, so if you are using capistrano to deploy your application, make sure you take advantage of it.

Pitfalls of Crontab

While using the whenever gem can fix some of the issues with using cron to manage your application’s recurring tasks, there are several reasons you may want to avoid using cron tasks at all:

  • It’s easy to forget to set up cron tasks on servers.
  • If you are running multiple servers, you may not want them all to run the cron tasks — doing so can cause conflicts or can at least require you to try to handle semaphores/locks in your code. This can get messy fast.
  • Cron schedules are maxed out at minute level. Scheduling for multiple times a minute is impossible.
  • If your server goes down, it could miss a critical scheduled task, so it often becomes a necessity to run cron more frequently and have the code account for missed runs.
  • Cron tasks can be difficult to debug. It is common practice to suppress all output, but by doing so you are possibly taking away a lot of good debugging information.
  • Each time a runner or rake task is run on a Rails app, the entire app has to be loaded into memory, which can take a substantial amount of CPU time and a substantial amount of memory. If your cron tasks start overlapping, you can quickly run out of RAM and cause your server to go kaput.

Despite the above issues, there are some cases where running a cron task is perfectly acceptable and possible better than some of the alternatives. When it is not absolutely essential that the task be run consistently, a cron job can be a quick and easy solution that doesn’t require a lot of setup. Combined with a whenever schedule.rb file and a deployment strategy that maintains your cron tasks, it can be a viable strategy.

Alternatives to Crontab

Sidekiq and Sidetiq

In cases where cron tasks don’t quite cut it, there are alternatives. My personal favorite is a combination of Sidekiq and Sidetiq. Understand, though, that these aren’t simple to setup. They require a redis server and additional code. When you run sidekiq, your application is loaded into memory and runs tasks as you schedule them in your code. This is nice because the code is constantly running and can quickly pick up new tasks and process them without additional overhead. When multiple application servers point to a single redis server (or server cluster) endpoint, you can also have multiple sidekiq instances pointing to that same redis server and have them pick off tasks as they have availability. This is great for scaling and (mostly) eliminates issues of locking, semaphores, and race conditions.

The Heroku Scheduler

Another alternative to cron tasks is the Heroku Scheduler, if your application is running on Heroku. As is noted in the documentation, the Heroku Scheduler does not guarantee that tasks will be run, so you are encouraged to include a custom clock in your application to make sure that tasks are run. It also has a limit of running at most once every 10 minutes, so you may need to use a worker dyno and create your own looping mechanism in a long running task to make sure tasks are run as frequently as they should be.

Conclusion

While cron jobs are useful, and can get the job done in many instances, you should be careful in your decision of how to implement scheduled and delayed tasks. Cron jobs are best for tasks that are not highly critical or essential to your application’s functionality or performance. They should also usually execute in a reasonably short amount of time so that they don’t bog down your server(s). When you have scheduled tasks of a critical nature, or tasks that need to be run more than once per minute, tools such as Heroku’s worker dynos or Sidekiq are very performant and viable solutions.

Microsoft Bets That Bitcoin-Style Blockchains Will Be Big Business

Earlier this week a consortium of 11 giant banks including UBS and Credit Suisse announced that they had completed their first trial run of the idea of using software inspired by the digital currency Bitcoin to move assets around more efficiently. It was also a test of what Microsoft thinks could be a significant new business opportunity. The experiment, coordinated by a company called R3 CEV using Bitcoin-inspired software called Ethereum, took place inside Microsoft’s cloud computing platform, Azure.

Many large banks have said they are investigating so-called blockchain technology (see “Banks Embrace Bitcoin’s Heart but Not Its Soul”), with Santander predicting this could save the industry $20 billion annually. Microsoft wants financial companies to host their blockchain software inside Azure. It has recently struck partnerships with several startups working on blockchain software for banks and other big corporations.

“We see a huge opportunity here,” says Marley Gray, who leads Microsoft’s project and is technology strategist for financial services at Azure. “Enterprise-scale and enterprise-grade infrastructure is going to be vitally important for this financial infrastructure that will be woven using blockchain over these next few years.”

The flurry of interest in blockchains is inspired by the way the software behind Bitcoin verifies and logs transactions. Each one is recorded in a public ledger known as the blockchain, maintained by a network of computers around the world. Cryptographic software verifies transactions as they are added and ensures that the historical record can’t be altered.

Banks want their blockchains to record not bitcoins but transactions in conventional financial assets, such as currencies, bonds, or derivatives. Startups and banks are also exploring a concept known as “smart contracts,” in which updates to a blockchain can add simple computer programs—for example, to automatically make a payout when a particular transaction occurs.

Banks also want their blockchains more private than Bitcoin’s, which is public and maintained by a community of strangers. Instead, companies using a particular blockchain would each run some of the software contributing to its upkeep. Gray says that doing that inside Microsoft’s cloud servers can let banks manage and deploy blockchains more easily, making them more reliable.

“I don’t think it will be solely in Azure, but it can be a backbone,” he says. Microsoft’s blockchain as a service also makes it easy to experiment with different takes on the technology as companies try to figure out what it’s good for, says Gray.

Despite much avowed interest in the technology from financial institutions, blockchains are not yet being put to work in any meaningful way. IBM, Cisco, and Intel recently formed an open-source project that will develop open-source blockchain software, but the most developed versions of the concept come from startups still testing and refining their products.

The mismatch between banks’ ambitions and the embryonic state of blockchain deployments has led to complaints the idea is overhyped. Chris Larsen, CEO of Ripple, a company with cryptographic ledger software being tested by partners including Accenture, says Microsoft’s involvement can help assuage such fears. “Microsoft adds credibility as to where the industry is going,” he says. Since last month, Microsoft has been running one of the software “nodes” that power Ripple’s ledger technology.

Still, to get beyond just experiments—and for Microsoft’s blockchain platform to become a significant source of income— this new approach will need to become as useful and reliable as more conventional approaches to managing corporate data.

“We should be comparing ourselves with other infrastructure companies like the Oracles and SAPs of the world,” says Chris Finan, CEO of Manifold Technology, which is testing its blockchain software with partners including the Royal Bank of Canada, and which is also a partner on Microsoft’s blockchain platform. “We need to prove why this kind of infrastructure is more efficient.”

 

MQTT protocol

MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The design principles are to minimise network bandwidth and device resource requirements whilst also attempting to ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices, and for mobile applications where bandwidth and battery power are at a premium.

MQTT is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based “lightweight” messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited. The publish-subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message. Andy Stanford-Clark and Arlen Nipper of Cirrus Link Solutions authored the first version of the protocol in 1999.The specification does not specify the meaning of “small code footprint” or the meaning of “limited network bandwidth”. Thus, the protocol’s availability for use depends on the context. In 2013, IBM submitted MQTT v3.1 to the OASIS specification body with a charter that ensured only minor changes to the specification could be accepted. MQTT-SN is a variation of the main protocol aimed at embedded devices on non-TCP/IP networks, such as ZigBee.

Historically, the “MQ” in “MQTT” came from IBM’s MQ Series message queuing product line. However, queuing itself is not required to be supported as a standard feature in all situations.

Alternative protocols include the Advanced Message Queuing Protocol, the IETF Constrained Application Protocol, XMPP and Web Application Messaging Protocol (WAMP).

MQTT methods

MQTT defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.

Connect
Waits for a connection to be established with the server.

Disconnect
Waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect.

Subscribe
Waits for completion of the Subscribe or UnSubscribe method.

UnSubscribe
Requests the server unsubscribe the client from one or more topics.

Publish
Returns immediately to the application thread after passing the request to the MQTT client.

Real-world applications

MQTT is designed to support wireless networks with varying levels of latency due to occasional bandwidth constraints or unreliable connections. There are several projects that implement MQTT.

  • Facebook Messenger. Facebook has used aspects of MQTT in Facebook Messenger for online chat. However, it is unclear how much of MQTT is used or for what.
  • IECC Scalable DeltaRail’s latest version of their IECC Signaling Control System uses MQTT for communications within the various parts of the system and other components of the signaling system. It provides the underlying communications framework for a system that is compliant with the CENELEC standards for safety-critical communications.
  • The EVRYTHNG IoT platform uses MQTT as an M2M protocol for millions of connected products.
  • On October 8, 2015, Amazon Web Services announced Amazon IoT based on MQTT.
  • The Open Geospatial Consortium SensorThings API standard specification has a MQTT extension in the standard as an additional message protocol binding. It was demonstrated in a US Department of Homeland Security IoT Pilot.
  • The OpenStack Upstream Infrastructure’s services are connected by an MQTT unified message bus.

On Ionic view caching and its effect

For a multiple view Ionic app, the controller for the state is attached to <ion-content> directive or tag. A few lines below are usually included in individual template (html) – note you don’t need to add ng-controller attribute.

<ion-view view-title="Home">
    <ion-content ng-controller="HomeCtrl">
       <!-- The content of the page -->
    </ion-content>
</ion-view>
 

Caching

By default, views are cached to improve performance. When a view is navigated away from, its element is left in the DOM, and its scope is disconnected from the $watch cycle. When navigating to a view that is already cached, its scope is then reconnected, and the existing element that was left in the DOM becomes the active view. This also allows for the scroll position of previous views to be maintained.

Caching can be disabled and enabled in multiple ways. By default, Ionic will cache a maximum of 10 views, and not only can this be configured, but apps can also explicitly state which views should and should not be cached.

Note that because we are caching these views, we aren’t destroying scopes. Instead, scopes are being disconnected from the watch cycle. Because scopes are not being destroyed and recreated, controllers are not loading again on a subsequent viewing. If the app/controller needs to know when a view has entered or has left, then view events emitted from the ionView scope, such as $ionicView.enter, may be useful.

Personal note: you include $scope.$on(‘$ionicView.enter’, function() { });  in the controller js file to catch the event and then execute the code inside function().

By default, when navigating back in the history, the “forward” views are removed from the cache. If you navigate forward to the same view again, it’ll create a new DOM element and controller instance. Basically, any forward views are reset each time. This can be configured using the $ionicConfigProvider:

$ionicConfigProvider.views.forwardCache(true);

Disable cache globally

The $ionicConfigProvider can be used to set the maximum allowable views which can be cached, but this can also be use to disable all caching by setting it to 0.

$ionicConfigProvider.views.maxCache(0);

Disable cache within state provider

$stateProvider.state('myState', {
   cache: false,
   url : '/myUrl',
   templateUrl : 'my-template.html'
})

Disable cache with an attribute

<ion-view cache-view="false" view-title="My Title!">
  ...
</ion-view>