If gpg isn't good enough for your use case, you're either protecting nuclear secrets or indeed a total cuckoo clock.
theamigan
joined 2 years ago
Basically. In Sony's case, they were clearly afraid of homebrew games, but I still can't imagine any other rationale than what you said for killing the feature, especially as neutered as it was. It definitely taught me a lesson about buying products that can't be kill switched after purchase. The US Air Force even built a cluster of 1700 PS3s that relied on this feature. I'm sure they weren't routable to the internet to get updates though.
My last straw was when they killed OtherOS on the PS3, which was very much part of my purchasing decision. Sure, it was kneecapped from the start (Linux still ran under the hypervisor, could not use the GPU, and was only given 6 Cell cores), but it was there. At least I got a $60 check from the class action settlement!
Bunch of cocksuckers. I have not purchased a Sony product since.
Sure, hence I said "hardly" rather than "is not." None of this excludes QUIC from also being transport layer.
Yeah. Wifi has more latency than switched ethernet on average (and really bad worst case latency since it is a shared medium, subject to neighboring RF interference that might not even be from the network, and radios try to handle retransmits on their own).
UDP is hardly a transport layer protocol. It basically adds port numbers and checksum to IP. QUIC is usually described as transport layer since it provides flow/congestion control functionality usually ascribed to transport layer.
There are a lot of variables that could cause that situation. Were both machines on the same physical link (ethernet vs wifi)? Changes to their RTT could influence it. The only thing I could really add is that you have found the reason QoS mechanisms exist, lol.
edit: I guess I can add this: if computer 1's download was from a host that has longer total round trip latency than computer 2's download, computer 2's download will return ACKs quicker and thus get PSH packets with data quicker than computer 1. This will lead to it filling available bandwidth more easily.
There is no allocation if you haven't configured any. Whoever can get their shit stuffed in the pipe first wins. From that point, any bottlenecks either FIFO to/from buffers, or if buffers fill up, just start taildropping. TCP (and other transport layer protocols like QUIC) implementations then have a sliding window algorithm that figures out the optimal amount of data to keep in flight at one time based on RTT and any packet loss caused by taildrops along the way.
TLB will always be translation lookaside buffer, sorry.
Uh, yeah. You think they just create themselves?
If you're on linux, you can use netns to run the client in a namespace with only the tunnel interface. No VM necessary.
Lol, thinking you're important enough for any of this. You sound like a teenager in his mom's basement who got way too high. I bet dollars to donuts you're in the US.