Friday, September 14, 2018


ICE (Interactive Connectivity Establishment) is a technique used in computer networking to find ways for two computers to talk to each other as directly as possible in peer-to-peer networking. It is a framework that allows peers to overcome the complexities of real-world networking, and communicate its public IP address so that it can be reached by other peers. It’s ICE’s job to find the best path to connect peers. It may be able to do that with a direct connection between the clients, but it also works for clients where a direct connection is not possible (i.e. behind NATs).

STUN (Session Traversal Utilities for NAT) server allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish the media connection. The STUN protocol is defined in RFC 3489. In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between clients.

TURN (Traversal Using Relay NAT) is an extension to STUN that allows media traversal over a NAT that does not do the “consistent hole punch” required by STUN traffic. TURN servers are often used in the case of a symmetric NAT.

Unlike STUN, a TURN server remains in the media path after the connection has been established. That is why the term “relay” is used to define TURN. A TURN server literally relays the media between the peers.

Although TURN almost always provides connectivity to a client, it is resource intensive for the provider of the TURN server. It is therefore desirable to use TURN as a last resort only, preferring other mechanisms (such as STUN or direct connectivity) when possible. To accomplish that, the ICE methodology can be used to discover the optimal means of connectivity.

Tuesday, September 4, 2018

Open source license

Recently we are discussing open source licenses including copyleft and copyright (GPL, LGPL, Mozilla, BSD, MIT, Apache etc). I briefed it in previous blog

In this blog, I want to discuss further more regarding if it is safe to use GPL or LGPL license and how to decide which open source license is safe for you.

The GPL is viral in nature (copyleft) so if you use or extend GPL-ed software then you are required to GPL your derived work. GPL Required you to release source code for your distribution (In case of Full GPL but not lesser-GPL which is much more common in libraries)

However, most libraries are intended to be reused and the GPL license doesn't make sense. That is why there is the LGPL or "Lesser GNU Public License". This license allows you to use GPL-ed code in a library setting without requiring your application to be GPL-ed. If the JAR file is distributed under the LGPL you should be OK.

Do not mix up with the following concepts using GPL
  1. You can still distribute any work for a fee thus making profit. (As long as you ship the binary with the source code)
  2. You don't have to provide source code, if you don't ship/distribute any binaries, in case of SaaS (Software as a Service)
If this program runs on your server, nobody else's, and other people only interact with the program by sending packets to your server, usually no source code release is needed. That's your computer, nobody else's. Since the GPL code doesn't execute on anyone else's machine, they cannot demand to see the source for the running program. There are exceptions but they consist of programs which transmit GPLed parts of their own source code to the client so that the client can run them; these need to satisfy the GPL of course. This is also why companies like GitHub (which uses git, GPLv2) or StackExchange (which uses Wordpress, GPLv2) don't have to open source their code, as interacting with their websites doesn't constitute distribution according to the GPL.

On the flip side, for example, when you send a virtual machine to someone, you are sending them code which they execute on their computers, and the GPL absolutely demands that they be able to control what's running on their computers: so you had best be prepared to release source code in such a case.

Here is one decision tree diagram from google search result (copyright owned by original owner). Hope it is clear. We can conclude BSD, MIT and Apache licenses are always safe.