Secure messaging client Bleep now allows for asynchronous chat.

Communicating privately with your friends, coworkers and family isn’t easy as you may think. While sending a “private” message may seem secure, the reality is that message still lives on a server somewhere, remaining vulnerable to third-party infiltration. In the past year alone, we have seen incidents of private photos and corporate emails being hacked and made public. This happens only because there is a honeypot, data stored in the cloud.
Continue Reading…

There are two central components in any secure communication: authentication and confidentiality. Authentication is the ability to be certain that the other end of a conversation is who you expect it to be. Confidentiality is your ability to communicate without an eavesdropper discerning what you are saying. In Bleep, we’ve also taken steps to obfuscate that you are talking to somebody, by not having a central repository of all metadata.
Continue Reading…

Every Test Automator’s dream is to slack off all day while their automation catches all the bugs.  Something that stands in the way of this paradise are visual bugs.  Though they are often minor, catching them involves an enormous amount of manual testing effort because:

  • Styling is usually shared across a project, so a change to make a button on screen A look better may make it look worse on screen B. This necessitates testing every screen individually.
  • UI-driven tests can not always catch the major ones, since tools may be able to find an element that’s been moved into a user-inaccessible area.
  • Testing is compounded by things like browser / OS compatibility, so you need to visually QA each environment individually.
  • You start having flashbacks to those awful “Find 5 Things Different About This Picture” newspaper puzzles.

Continue Reading…

At BitTorrent, our team of engineers are managing a complex set of tasks across many versions of our growing products. Perhaps no team feels the squeeze now than the engineers working on Sync as it transitions to 2.0. Sync Engineer and frequent blog contributor Richard Brooks recognized the difficulty of tracking the progress of Sync across Windows, Mac, Linux, and FreeBSD:
Continue Reading…

How Does Bleep Work?

Farid Fadaie —  September 17, 2014 — 13 Comments

We unveiled Bleep a few weeks ago, and we have received nothing but love from our users. We’ve also had many great questions that we will be gradually answering in blog posts, our forums and other social channels. And today we’ve taken a step further, bringing Bleep to Open Alpha and adding clients for Mac and Android. There’s more to Bleep than we can fit in a single blog post, but here’s an overview of the big picture, including some high level technical details and answers to some of the questions around how Bleep works.

Continue Reading…

Installing Mavericks inside a virtual machine is fairly easy, but there are a few tricks to be aware of if you’re on a newer Mac. Credit to Natsuki’s post for sharing how to get the Mavericks installer to run on Apple computers with Intel Haswell CPU’s. Natsuki also notes a workaround for Apple computers with ECC RAM that requires the removal of a kernel module from the install image using iesd.

Download and install the latest VirtualBox for OS X hosts from here. We’ll be using VirtualBox so that anybody can follow these steps.

Download the Mavericks Installer App through the App Store.The Mavericks installer is provided for free by Apple for users to upgrade their computers to the latest version of OS X. We’ll be making use of the install image provided by this application to install Mavericks within a virtual machine.

While we’re waiting for the Mavericks Installer to download, lets get started on configuring our new Virtual Machine.

Create a New Virtual Machine

2014-06-13_1303
Continue Reading…

uTorrent

Our flagship torrent clients, uTorrent and BitTorrent, do many different things in the course of downloading content onto your computer faster than what’s physically possible with other protocols. There is a lot of functionality going on under the hood in the course of a download, which fall into three broad categories: networking, disk IO and user interface. We have written before about enhancements in the first two categories (uTP, DHT and multithreaded disk IO, for instance) and are now pleased to announce new improvements in how the user interface interacts with the rest of the system.

In addition to requesting and sharing pieces of files on the network and assembling them on disk, the client needs to convey these activities to the user by showing them on the screen. The logic which displays this information often interacted with the rest of the program in a coarse and intrusive way, requiring networking and/or disk IO to briefly halt while the information was gathered. For example, while viewing the list of files contained in a torrent and their relative download progress, the networking subsystem would be halted several times a second. However brief these pauses were, when multiplied by several UI elements and possibly large lists of torrents and their files, it was enough to slow overall performance.

As an analogy, consider a car’s speedometer as the user interface and the engine, transmission and wheels as the core subsystem doing the work. If the engine had to pause several times a second to update the state of the speedometer, performance would suffer.

To avoid these pauses, the layer between the UI and the rest of the system was made richer and less synchronous. Instead of pausing the subsystem to interrogate values, the UI first conveys broadly what it is interested in (which tab is visible, which torrent is selected), and the subsystem then asynchronously presents only the updated information relative to that state. The user interface layer is then free to present this information without holding up the other layers.

This is an exciting update for us to issue, as the entire engineering team is constantly refining products to try and provide the best user experience.

There’s always more to come on this front, so do stay tuned!

BitTorrent Tech Talks are one-hour sessions dedicated to the stuff that keeps us busy / keeps us up at night / keeps us coding. From time to time, we post them here. Because sharing.

In this edition of Tech Talks: an overview of some C++ gems. I threw this talk together because my team was about to start a new project in C++11. Since it’s fairly new, I figured some of it might not be as well-known as it should. Fundamentally, I’m pretty excited about all the new possibilities in C++11. Even higher-level abstractions, at even lower cost than C++98.

In the video below, we go over for-loops, automatic type deduction, lambda functions and more.

Correction: I say that lambdas with an empty capture statement defaults to by-value, which is incorrect. It defaults to not capturing anything.

Follow along with the C++ in the 21st Century slides:


 

Looking for more on BitTorrent engineering? We’ve got Tech Talks aplenty. Check out Distributed Hash Tables, DHT Bootstrap Update, and Writing High Performance Software.

client-hero-torrents

3.4 is an exciting release for the uTorrent team.

3.4 is the first version to include a major change in the way that uTorrent chooses peers in a swarm. Designed by our own Arvid Norberg, Canonical Peer Priority is a way to help peers connect to the swarm faster, as well as reduce the average hop length from you to any other peer in the swarm.

When a bittorrent client joins a swarm, it needs a way to select which peers it connects to. If it chooses poorly, or if there are malicious actors in the swarm, the connections between clients are not well distributed through the swarm, leading to a large number of hops from node to node. That slows down the ability to each client to pass data on to the next.

You can read a more detailed technical discussion of the issues here, along with graphs and figures that drive home how bad the worst case can be. You can read more about graph connectivity here.

Perhaps one of the biggest changes, though, is one you cannot see. Our engineering team has been growing rapidly, and we have been busy changing our development and release processes. uTorrent 3.4 will mark the first release using improved processes that should allow us to release much more often, while keeping stability at the levels you have come to expect from the world’s fastest and lightest torrent client.

Our previous release cycle was slow. We followed the traditional alpha -> beta -> stable model that a lot of software development follows, for example large video games or operating systems. One of the problems with this style of development is as stabilization work continues on the features you just developed, new features are requested, or requirements change, and now you have to balance two lines of development in the same tree.

Also, with more developers, more changes can be made simultaneously … in theory. In reality, changes in unrelated modules (e.g. the installer) would impact when we could ship new code in other areas (e.g. the disk code), and of course, vice versa. This creates a vicious cycle, where each small problem creates a knock-on effect that impacts other features.

In a situation like this, instead of asking the business to “pick one thing and stick with it” the correct response is for the engineering team to change how they operate.

* On a small scale, picking one thing and sticking with it.
* On a larger scale Multiplexing the work into separate branches.

We needed a way to release changes fast and reliably. This implied quite a few things:
* Don’t mix changes
* Release fast, review results fast

This required us to build a few systems. Some of the larger ones:
* Our release system (code-named “Cherry”)
* Or automatic update system (code-named “The automatic update system”)

It also required programming policies into the smaller parts of the system that already existed
* The build server
* The version control system
* New test servers

These systems, working together, can now answer the question: Is this feature ready for release?
Will deploying this feature likely increase or decrease the crash rate?

We now build individual features in separate branches, which are automatically tested for stability before being integrated into the mainline. That gives us confidence that we won’t slow other engineers down, and that we won’t release a low-quality build to customers.

This effort would not have been possible without the support of the excellent engineering team at Bittorrent.

I look forward to covering these in detail in later posts.

From the uTorrent engineering team, and the rest of Bittorrent as a whole, Happy torrenting!

BitTorrent Tech Talks are one-hour sessions dedicated to the stuff that keeps us busy / keeps us up at night / keeps us coding. From time to time, we post them here. Because sharing.

In this edition of Tech Talks: BitTorrent’s Chief Architect Arvid Norberg describes how modern computers work, and the key challenges to software performance. He then breaks down how to modify data structures to better take advantage of your memory cache. Want to write your own high performance software? Watch the full video, or follow along with the slides below.


Writing High-Performance Software by Arvid Norberg from bittorrentinc

For more talks by Arvid, check out distributed hashtables and his follow-up, distributed hashtables updated.