This is not the first time something like this has been done, Erik Ekman made PingFS, a file system that stores data in the internet itself .
This works because inside every ping packet is a section of data that must be sent back to the system that sent the ping, called the data payload.
Because you can put up to 1400-ish bytes in this payload, and pings take time to come back, you can use the speed of light in fiber as actual storage.
Now obviously this is not a great idea for long term data storage, since you have to keep transmitting and receiving the same packets over and over again, plus the internet gives no promise that the packet won’t be dropped at any time, and if that happens then the data is lost.
However. DNS has caches. It has caches everywhere.
Obviously, neither DNSFS, nor PingFS should be used for anything serious, but both are excellent experiments, demonstrating the flexibility of the TCP/IP and thinking outside the box.
The servers of Telegram, a popular instant messenger, were under a DDoS attack recently. While they were working on the problem, they’ve tweeted a couple of explanations of what’s going on. CNET brings those tweets to our attention, as they explain rather complex things in a very short and simple way.
“Packets-per-second limits in EC2” is an interesting dive into network limits on the Amazon EC2. Even if you aren’t hitting any limits yet, this article provides plenty of useful information, including benchmarking tools and quick reference links for Enhanced Networking.
The conclusion of the article is:
By running these experiments, we determined that each EC2 instance type has a packet-per-second budget. Surprisingly, this budget goes toward the total of incoming and outgoing packets. Even more surprisingly, the same budget gets split between multiple network interfaces, with some additional performance penalty. This last result informs against using multiple network interfaces when tuning the system for higher networking performance. The maximum budget for m5.metal and m5.24xlarge is 2.2M packets per second. Given that each HTTP transaction takes at least four packets, we can translate this to a maximum of 550k requests per second on the largest m5 instance with Enhanced Networking enabled.
Recently, I had an issue with one of the servers, where a bunch of services were attaching to IPv6 ports instead of the IPv4 ones. Rather than editing the configuration of each of these services, I wanted to simply disabled IPv6 on the machine.
In the old good days, things like these were easily done via the sysctl. I surely tried that option too, but it wasn’t enough. Turns out, the proper way these days is to do this via Grub, as per this blog post:
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.