Research

Today I finally completed building my own private CDN. As I discussed so far in my earlier topics (Building my own CDN), I want to custom build the same step-by-step from scratch. And I don't want to for now use/buy third-party CDN subscriptions from Akamai, CloudFlare, Limelight, etc as I discussed earlier.

Here is a complete log of my lab battery purchase, service record which I maintain in Google drive. These I use for my home (or my family generic use) as well as a part of my home lab. I maintain a detailed log this way to monitor the failure rate of these batteries. This will allow me to select a specific brand/model which has higher success rate and to monitor any premature failure/expiry. The service log helps me to monitor and schedule the next service routine so that I can maintain these batteries in tip-top condition.

Assume you have two sites (such as Site-A and Site-B) connected via slow/critical WAN link as shown below. You can optimize this link by saving the bandwidth as well possibly improve the speed. However, the WAN speed can be optimized only if the WAN link speeds are below that of the processing latency of your TOFFEE installed hardware. Assume your WAN link is 12Mbps, and assume the maximum WAN optimization speed/capacity of Raspberry Pi is 20Mbps, then your link will get speed optimization too. And in another case, assume your WAN link is 50Mbps, then using the Raspberry Pi as WAN Optimization device will actually increase the latency (i.e slows the WAN link). But in all the cases the bandwidth savings should be the same irrespective of the WAN link speed. In other words, if you want to cut down the WAN link costs via this WAN Optimization set up, you can always get it since it reduces the overall bandwidth in almost all the cases (including encrypted and pre-compressed data).

Here is my video article on Network Latency in WAN Networks (such as long distance Satellite links, etc) and how you can optimize the same to achieve better network performance.

Assume you have two sites (such as Site-A and Site-B) connected via slow/critical WAN link as shown below. You can optimize this link by saving the bandwidth as well possibly improve the speed. However, the WAN speed can be optimized only if the WAN link speeds are below that of the processing latency of your TOFFEE installed hardware. Assume your WAN link is 12Mbps, and assume the maximum WAN optimization speed/capacity of Raspberry Pi is 20Mbps, then your link will get speed optimization too. And in another case, assume your WAN link is 50Mbps, then using the Raspberry Pi as WAN Optimization device will actually increase the latency (i.e slows the WAN link). But in all the cases the bandwidth savings should be the same irrespective of the WAN link speed. In other words, if you want to cut down the WAN link costs via this WAN Optimization set up, you can always get it since it reduces the overall bandwidth in almost all the cases (including encrypted and pre-compressed data).

Today I have done a test setup so that I can able to connect my Android Samsung Tab via TOFFEE DataCenter. Below is my complete test topology of my setup. For demo (and research/development) context I configured TOFFEE DataCenter in engineering debug mode. So I do not need two devices for this purpose.

Here is a list of TOFFEE-DataCenter features supported. TOFFEE-DataCenter currently supports some of the important features such as loss-less network data compression, Packet Deduplication (protocols/applications supported), Application Acceleration, TCP Acceleration, dynamic MTU optimization, data packaging, hardware offload support, etc.