I’m looking at libev, a replacement for libevent that provides the same features but with some important improvements, like a good documentation with nice examples, better support for multi-threaded programs (with different loops and fast intra-thread communication), file watchers, absolute timers, C++ support…
Here is a nice example of the libev performance: a very simple web server that can be embedded, only takes 188KB of memory, and it still beats all the other “fast” servers (ie, nginx).
TFRC is a congestion control mechanism designed for media transmission. It has a much lower variation of throughput over time compared with TCP and, at the same time, it is reasonably fair when competing for bandwidth with TCP flows (ie, it is TCP-friendly). This smooth sending rate variation makes it an ideal option for the transmission of audio or video, as the receiver needs less buffering for balancing the input and output rates at the playout buffer.
Some time ago I implemented TFRC and integrated it in the Ultragrid project. However, TFRC was a pain when used in local are networks, environments with very short RTTs and huge data rates. The main problem was with the timeout used by TFRC for detecting lost packets.
A TFRC sender will expect a feedback from the receiver every RTT. In order to detect lost feedbacks, it sets a timeout equal to four times the RTT, and, if it doesn’t receive a feedback in that time, the sender will consider that there are some problems…
But, in local area networks, the RTT can be really short (in the order of microseconds), and high data rates can result in lots of interrupts (due to many packets going in and out thru the network card), so the receiver will not get the CPU so often as it would like, being preempted in many occasions. The receiver will then be late sending feedback many times, and the sender will fall back to a safe sending rate too often, leading to some sending rate instability.
Today I discovered a posible solution for this problem. In RFC2988 they deal with the timeout estimation problem for TCP, and the same calculation can (or, should I say, must) be applied to TFRC. This would lead to a more complex sending rate calculation, but it would probably provide greater stability…
From NewTeeVee:
Adobe and Broadcom Corporation announced today that Flash will be integrated into Broadcom’s latest digital television and set-top box system-on-a-chip platforms. The partnership will make it easier to watch web video on your TV, and comes one day after Adobe announced a similar chip partnership with Intel.
[...]
Flash is the dominant video platform on the web, and Adobe wants to keep it that way as more televisions start receiving online video. ABI Research predicts that, thanks to more Net-connected TVs, the number of people watching online video will boom to 941 million in 2013, up from 563 million at the end of 2008. Getting in on the chip level with biggies like Intel and Broadcom is one tactic to ensure Flash’s dominance.
Broadcom’s Flash-supporting chips are expected to be available to manufacturers in the first half of this year.
It seems clear that flash will become one of the main frameworks not only for getting IPTV into your PC, but also for accessing this content from your STB: maybe Java is loosing ground…
Take a look at how Boxee does this with Hulu. They embed their flash player, but they still keep Hulu happy as they will not lose control on the content and how it is displayed: they are just making Hulu reach more users. And they do the same with other channels (ie, Comedy Central) and IPTV offerings (ie, iPlayer)…
From the BBC Internel Blog:
[...] our new BBC iPlayer Desktop no longer uses P2P. Downloads now come directly from our servers, as direct HTTP downloads. Why the move away from P2P? Three reasons:
1. When the BBC chose P2P for downloads over two years ago, bandwidth was really expensive, and so P2P was seen as the only way of providing a download service at a sustainable distribution cost. But over the past year the cost of bandwidth has decreased by 90%, making direct HTTP downloads a viable alternative.
2. Some users told us that they didn’t like P2P – it used their CPU, used their upload bandwidth, slowed their computer. Our new solution should not have those issues.
3. In the UK, some ISPs count both download and upload internet traffic in their usage calculations, which means that some users were hitting their monthly usage caps more quickly because of P2P upload traffic. Our new solution doesn’t have that issue (of course if you download lots of stuff you may still hit you monthly ISP limits – but that applies not just to iPlayer content).
The problem with P2P for media delivery is that someone else can come with a cheaper streaming solution and without all the hassle of P2P. HTTP downloads can be a good alternative for serving non-live audio and video to your clients, specially for content that can be mirrored and cached (ie, with akamai).
So, why would you choose a P2P solution? There are several cases where P2P makes sense:
I’m currently evaluating some alternatives for network simulations with virtual machines in Linux.
So far, the best solution available would be Xen, but other good solutions would be OpenVZ and Linux VRF. Linux VRT provides separate networks profiles for processes, so that one process can have some interfaces, firewall rules and routing table, while other processes will be associated with other devices and tables. OpenVZ is a containers solution (something like Solaris Zones), where this isolation between processes is not only done at the networking level but at an OS level, with their own node name, virtual network interfaces, storage, etc.
Xen is not the best performer. The performance problem comes from the overhead introduced by systems calls: when a guest VM sends a packet to the network, it has to be processed by the guest machine, make a context switch and be processed again at the host OS. As a result, network performance is not as good as a native machine, but its is still one of the best in its class.
However, Xen is probably the best supported solution in the market nowadays. There are a lot of configuration tools, web interfaces, and some network simulation tools. For example, MLN looks like a nice application for creating virtual networks: you have to define the topology in a very simple configuration file, and you get a bunch of Virtual Machines connected with virtual LANs, hubs, routers and so.
