Hey everyone, Iโm #newhere. Iโm interested in #nft, #nfts, #nftcommunity, #networking, #4thsector, #business, #business-development, #blockchain, #crypto, #decentralize, #discord, #entrepreneur, #ethereum-blockchain, #global-change, #global-solutions, #growth_mindset, #metaverse, #nftgiveaway, #opensea, #opensearch, #self-development, #social-responsibility, #technology, #universal-immersion, #ai, #web3 and more! Please feel free to reach out!!
The Internet just changed. What this is about is a protocol called QUIC, that is in essence a replacement for TCP. This video does an impressive job of distilling knowledge from dry RFCs into something us mere mortals can understand. The underlying protocol of the internet is IP, which stands for Internet Protocol. It basically deals with moving a packet of information from one place to another. And that's all it does. It doesn't have any concept of a "connection", and any notion of reliability, i.e. if a packet gets lost, IP doesn't notice. That's why TCP, which stands for Transmission Control Protocol, was invented. It creates the concept of "connections", it gives packets "sequence numbers", it notices when packets arrive out of order and rearranges them, and if they don't arrive at all in which case it will request they get retransmitted. It is the TCP protocol that QUIC aims to replace.
But since TCP is embedded deeply in operating system kernels, replacing it with anything else would be hard. But alongside TCP, the makers of IP also made a parallel networking service called UDP, which stands for User Datagram Protocol. It is almost IP packets and nothing else. Well, there is a little more -- UDP provides checksums to detect errors and it also has the TCP concept of port numbers. But that's it. It has no concept of connections. With QUIC, they figured out how to invent a new TCP replacement by building it on UDP. In fact QUIC stands for Quick UDP Internet Connections.
But first, we have to ask, why would anyone want to replace TCP? It turns out that engineers since the invention of TCP have figured out how to make the "handshake" process more efficient. The "handshake" is the initial back-and-fourth process that enables the two sides to set up a connection between each other. Not only that, but immediately after a browser sets up a TCP connection, it has to do another handshake to set up the encryption, so the communication connection is secure. The protocol to do this is called TLS, which stands for Transport Layer Security. What the inventors of QUIC figured out how to do is do both the connection handshake and the encryption handshake simultaneously, and efficiently. In practice this means when you connect to a website, you get the first part of your webpage faster (what in computer science parlance is called lower latency).
QUIC doesn't stop there. With regular TCP connections, missing packets can cause one side or the other to wait while retransmission is requested and packets arriving out of order get properly resequenced. QUIC is smart enough to know when packets are interdependent and when they're not. So for example it can figure out it's got all the packets for an image so the browser can go ahead and display the image to you, but it doesn't have all the packets for the JavaScript so it can't run the JavaScript yet.
QUIC was invented by Google and has already been deployed in the Chrome browser, so if you're using Chrome, you're using it already. Microsoft Edge and Firefox already support it. On the server side, not just Google but many other major companies like Facebook (er, Meta), have already rolled it out. This was all possible because it's able to run on UDP and doesn't require operating systems to be upgraded to upgrade TCP.
The only downside is that many routers and firewalls block UDP completely for security reasons. But even here, rather than have to have everyone buy new routers and firewalls, it's possible to enable it by changing the settings on existing routers and firewalls. It will take time for security professionals to make this change, and some will never do it because the higher encryption level of QUIC means it's harder to tell what traffic is going through a router or firewall, and some people will never be comfortable allowing traffic they can't see. That's why browsers have to have the ability to fall back to regular TCP.
The Amiga 500 was the low-end, entry level machine back in the day but in 2022 I give it some EXTREME upgrades. Fitting a brand new Crystal Case and using a #RaspberryPi to boost the speed by over 1000x!
โฌ Contents of this video โฌ
00:00 - Introduction & #Amiga500
01:50 - A1200.net Crystal Case
2:32 - #Unboxing #Crystal #Case
03:19 - Fitting #Amiga 500 Crystal Case
04:54 - #PiStorm Recap
05:57 - #Emu68 Introduction
06:53 - Squarespace Sponsor Slot
07:55 - Caffeine OS Introdution & Install
09:38 - #CaffeineOS Tour
11:40 - #Networking & #Internet
13:16 - Bundled #Utilities
14:38 - SysInfo #Benchmarks
15:04 - #Scene #Demos
15:25 - #Game #Performance
16:12 - Conclusion
https://www.youtube.com/watch?v=3s1_XCv-f1o
#retrocomputing #retrogames #retrogaming #amiga #raspberrypi
See also https://twitter.com/atoonk/status/1550896347691134977
https://www.kentik.com/blog/a-deeper-dive-into-the-rogers-outage/
Jim Cowie auf Twitter: โ"a detailed 15th century map of the modern Internet, showing BGP routes and IXPs" https://t.co/bqaSKVhAyDโ / Twitter
#networking #bgp Hah!
GNU Linux (distro independent) - how to set fixed ip - temporarily
this is a quick bash hack, to set an additional fixed ip to the user's interface, this will (brute force) OVERWRITE all mess done by network managers of various origins: (there should be only one config file to config network settings and[...]
#linux #gnu #gnulinux #opensource #administration #sysops #gnu-linux #networking #lan #connect #ip
Originally posted at: https://dwaves.de/2022/05/19/gnu-linux-distro-independent-how-to-set-fixed-ip-temporarily/
โจ๐ฟ๐๐๐๐ โก๏ธ auf Twitter: โthere are many health benefits to a high fiber diet https://t.co/b0tyzzq1pJโ / Twitter
Reticulum allows you to build very wide-area networks with off-the-shelf tools, and offers end-to-end encryption, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable packet acknowledgements and more.
Reticulum is a complete networking stack, and does not need IP or higher layers, although it is easy to utilise IP (with TCP or UDP) as the underlying carrier for Reticulum. It is therefore trivial to tunnel Reticulum over the Internet or private IP networks. Reticulum is built directly on cryptographic principles, allowing resilience and stable functionality in open and trustless networks.
It can be used over practically any medium that can support at least a half-duplex channel with 500 bits per second throughput, and an MTU of 500 bytes. Data radios, modems, LoRa radios, serial lines, AX.25 TNCs, amateur radio digital modes, ad-hoc WiFi, free-space optical links and similar systems are all examples of the types of interfaces Reticulum was designed for. An open-source LoRa-based interface called RNode has been designed specifically for use with Reticulum.
No kernel modules or drivers are required. Reticulum runs completely in userland, and can run on practically any system that runs Python 3. Reticulum runs well even on small single-board computers like the Pi Zero.
Reticulum should currently be considered beta software. All core protocol features are implemented and functioning, but additions will probably occur as real-world use is explored. There will be bugs. The API and wire-format can be considered relatively stable at the moment, but could change if warranted.
So 3rd part apps can be built which use this networking stack to communicate. One such example is LXMF, which is a distributed, delay and disruption tolerant message transfer protocol built on Reticulum. Nomad Network is an example of an off-grid, encrypted and resilient mesh communications platform. The Android, Linux and macOS app Sideband has a graphical interface and focuses on ease of use.
See https://github.com/markqvist/Reticulum
#technology #networking #security #privacy #reticulum
#Blog, ##networking, ##opensource, ##privacy, ##reticulum, ##security, ##technology
Hey everyone, Iโm #newhere. Iโm interested in #an, #and, #biographies, #canadian, #international, #lagagnonnieresettlement, #musical, #networking, #politics, #social, and #videos.
Thanks to Julius Caesar for first implementing the encoder used in this task back in ~50 B.C. and helping to crack a modern packet inspecting firewall some 2071 years later :)
https://gist.github.com/gmurdocca/88857b58dc4668d88b0d0fae6ebf8b64
Hey everyone, Iโm #newhere. Iโm interested in #an, #and, #biographies, #canadian, #international, #musical, #networking, #politics, #social, and #videos.
Hi, for those of you who don't know me, I'm Steven J. Vaughan-Nichols, aka sjvn, and I'm a technology and business journalist. I'm interested in #Linux, #opensource, #security, #networking, #music, #theater, #art, and #reading, Besides sharing a lot of tech stuff you'll also find me sharing a goodly number of things I find amusing. Hopefully, some of you will find them funny too.
When I upgraded my cable ISP tier to 1000/50 I quickly noticed the old 2011 OpenWrt router wasn't up to it, downstream consistently maxed out at around 260mbps. That said, its nearly always TCP offloading, and needs beefier hardware if you can't use that. I went to a downstream north of 420mbps and often go into the 600mbps region even with ac wifi. Upload otoh hasn't improved, meh.
Over at the OpenWrt forum there's a posting to answer all postings on how el cheapo CPUs fail:
Let's take a look at the math: At 1Gbps using 1500 byte packets, you need to send/receive 83333 packets per second. The packets need to be received by an interrupt, go through the firewall, be inspected, maybe have NAT applied, sent into a queue, the queue calculates rates to avoid over-sending on the link and causing buffers, and then hardware interrupts are serviced to actually send the packet along...
At 1 GHz processing rate, each packet gets 12000 clock cycles of calculation if the CPU is maxed out doing nothing but processing packets.
Evidently in an ideal world, we should have maybe 1.2GHz processors or better, and maybe have two cores at least one can handle interrupts on the receive interface, and one can handle interrupts on the send interface, and they can share the firewall and queueing duties.
Still, because DOCSIS cable is a shared medium and oversubscribed ISP-wise, the throughput is wonky and inconsistent. But at least I know not my own CPU is to blame so I can point fingers at my provider vodafone. And I'd totally want to go 500/100 if only I could mix and match features. Sigh.
TL;DR Going cheap, stick with proprietary firmware to keep the TCP offloading feature, or gear up. A Turris Omnia should be fine, or any of the suggestions in the thread. I went with OPNsense on a small x86 box.
#openwrt #gigabit #throughput #docsis #docsis3.1 #docsis4 #wan #networking
https://twitter.com/mainframed767/status/1485389484258521090
Given less voyeurism, testing bandwidth can also be done this way and with less side effects. Set desired bandwidth with e.g. -L 12M for 12mbps and send them a constant stream with they pipe into /dev/null like this:
pv -r -L 32M /dev/urandom | ssh user@my.testserv.er "cat > /dev/null"
On Gentoo pipe view pv is available as sys-apps/pv.
