Our Technology

Bolina a newer, faster

Codavel Performance Service is built on top of our core technology, Bolina: A mobile-first protocol that outperforms HTTP, including its latest version, HTTP3 (based on QUIC). Bolina is capable of handling the worst network conditions, presenting robustness against latency and packet loss, regardless of the user’s network, device, location, or time.


Tackling the problem
at the root

TCP is the foundation for today’s reliable internet communication. Protocols like the dominating HTTP rely on TCP for data transport. The problem is that TCP was designed for a wired world, not dealing well with the inherent instability of wireless links. For example, just 0.1% of packet loss brings speed down by 5 times. The standard approach is to rely on infrastructure-based solutions, such as caching, but it does not help much: the largest portion of link instability happens in the last mile. That’s why we decided to tackle the problem at its root: the protocol.


Bolina, TCP and QUIC

TCP has been revisited several times over the years, in particular with respect to its congestion control mechanisms. More recently, QUIC (which works over UDP transport) has been proposed as an alternative to TCP. With a cross-layer approach to transport and security, by combining TCP and TLS roles, QUIC enables significant improvements in connection establishment. Nevertheless, both these protocols take the same approach to handle packet loss: relying on feedback to recover from losses. In other words, TCP and QUIC are both ARQ-based protocols.



Consequently, both protocols are highly impaired by the latency of the link, in particular in lossy links. And that’s precisely what characterizes wireless links (like WiFi, 3G, 4G or even the upcoming 5G): significantly higher latency and packet loss. In contrast, Bolina relies on Network Coding to overcome packet loss, which makes it more robust to packet loss and latency.
In a single word: faster.


Network Coding for packet
loss recovery

What makes Bolina unique is that it was built on top of network coding techniques, which mixes original data packets into coded transmissions. This approach enables revisiting the role of feedback information. In a nutshell, Bolina relies on two fundamental principles: 1) feedback is not necessary for packet loss and 2) feedback is used to assess link quality.

1. Feedback is not necessary for packet loss recovery

Standard Protocols

Standard protocols recover from packet loss by using feedback. This means that the sender needs to wait for feedback (ACK) before sending new data.



Highly impaired by the time it takes to receive that
feedback (~latency)




Mixing original data packets into coded transmissions to overcome losses enables the following:


– Recover from packet loss independent from feedback


– No need to wait for feedback before sending new data


This allows higher robustness to latency

Remark: Network coding techniques enable live link assessment, which means that no pre-established redundancy is necessary (in contrast with standard Forward Error Correction techniques). This translates into no useless transmissions. Bolina’s overhead is below 0.1%.

2. Feedback is used to assess link quality

Standard Protocols

Standard protocols can’t understand the nature of packet loss. The sender always assumes losses happen only due to congestion. This is not always true, especially in wireless. This is why standard protocols decrease speed when it is not necessary.


Coded transmissions solve the losses, feedback is only used for link quality evaluation, in particular, to evaluate loss nature. This way, the sender is capable of distinguishing losses due to congestion from other losses.


Deploying Bolina in a mobile app: UDP

Bolina is not a new improvement to TCP, it is an entirely new protocol. Therefore, in order to deploy Bolina in a mobile app, it is necessary to be able to do it in user space. That’s why Bolina protocol is deployed on top of native UDP sockets, ensuring that you can benefit from Bolina in any mobile app, in any mobile device, in any network. In other words, we use UDP as the underlying protocol to avoid requiring changes to operating systems and middleboxes. Bolina is also capable of detecting if UDP is blocked on the users’ network, or if UDP links are throttled down by the network operator. In these cases, Bolina will make use of TCP, ensuring that the end-user experience is not affected.

Inside Bolina


The number of simultaneous connections affects how your system handles scalability. Bolina Client efficiently groups multiple requests to the same server within the same connection to avoid the unnecessary increase of the server load.

No OS modifications

Client and Server run at the application layer. No special permissions are required. This is possible because Bolina uses UDP to have full control of the link. Bolina also makes use of TCP in links where UDP flows are impaired for network policy reasons.

Compatibility with any app layer protocol

Bolina is implemented as a socket, with the same features as a regular TCP socket, but at a higher speed: reliable and ordered delivery, and congestion control. Therefore, it can be integrated with any application layer protocol, such as HTTP, SCP and FTP.

0-RTT handshake

Bolina enables a zero round trip time handshake. Similar to TLS 1.3, with this feature the client does not waste time establishing a connection to an already known server.

State-of-the-art security

With end-to-end security enabled by default, the privacy of your data is guaranteed with well-known standards for encryption and authentication (ChaCha2020 and Poly1305).

Seamless integration via Codavel SDK

Codavel SDK allows you to deploy Bolina without having to modify your app architecture, with off-the-shelf integration with AFNetworking, Alamofire and OkHttp. Codavel SDK also works with any other HTTP/HTTPS library.