12 ms·
NoTCP
- jcoffland 11y agoThis article has a ring of truth. With HTTP/2 gaining traction I cannot help but wonder if a lot problems could be solved by going down a level of complexity instead of stacking more layers on top of TCP. For example why not allow UDP from Javascript in the browser with CORS like protections to limit DOS attacks. I.e., only allow UDP connections back to the origin unless the server explicitly allows non-origin access from the requesting domain. This approach seems a lot simpler and opens the doors to all kinds of improvements not just those designed into HTTP/2.
- Nadya 11y agoI'm scared to click the link because of the URL. ... ... ...
- vezzy-fnord 11y agoDon't worry, it's just "yet another hipster technology manifesto" (their quotation).
- Navarr 11y agoThis is too low level for me. I don't care. I don't care about TCP, I don't care about UDP, I only care about QUIC because I'm a Google fanboy. I shouldn't have to care about this. All I want is some very fast, very reliable underlying protocol for my web apps and api endpoints to run on.
- tjbiddle 11y agoHacker News caters to a wide audience. While it may not be of interest to you, someone else is geeking out over it.
- eloff 11y agoAnd because you and most people don't care, you're stuck with TCP instead.
- amyjess 11y agoYou know this is a joke, right?
- kstrauser 11y ago> I shouldn't have to care about this. You don't have the privilege of not caring about, at least if you're in the position where you have to make decisions involving it. Quick: what's best, ints or strings? That entirely depends on how you want to use them, doesn't it?
- larvaetron 11y agoPerhaps you should post this comment on Navarr News instead.
- krschultz 11y agoThat's fine, but don't call yourself a software engineer. Programmer or developer sure, but engineers understand the underlying layers. Otherwise when shit really hits the fan you will only be able to throw your hands up and consult stack overflow.
- ianamartin 11y agoI completely lost it when I got to this line: "So suppose we’re conscientiously setting artisanal timeouts for all our TCP messages." Well done.
- andrewmcwatters 11y agoThis is not new. This is an attempt to make something that has existed for decades seem new, hip, and edgy. Prefixing "no" to existing traditional technologies does not make something new or cool. The only people who would buy into this are people who have no experience with networking, and thus this would only affect their probable usage of libraries down the road with the wrong intentions. Hell, I don't even know who this is really suppose to address. My best guess is people with very little knowledge of network protocols and their usages.
- amyjess 11y agoThis is a joke. They're making fun of NoSQL and its ilk.
- andrewmcwatters 11y agoI seriously could not tell. I don't know if I'm just not fully paying attention or they put more effort into this than needed.
- AceJohnny2 11y agohttp://en.wikipedia.org/wiki/Poe%27s_law http://en.wikipedia.org/wiki/Poe%27s_law
- golanghacker4 11y agoI don't think they are. Other than the first paragraph, with its self-deprecation and references to Node.js and NoSQL, which seems intended to head-off the derision such a hipsterish manifesto would rightly incur, the rest seems entirely serious.
- EdwardDiego 11y agoHa ha, only serious.
- nemo 11y agoThe very last link in their "are you serious?" section is the sentence "Or maybe you have some clue about how the internet actually works, and you don’t need a manifesto to tell you what you already know" with a link to an article titled "TCP doesn't suck, and all the proposed bufferbloat fixes are identical." I read the whole thing as a joke, and I don't see anything that suggests otherwise anywhere in it. Seriously, how can you read "just as the Reactive Manifesto reminded us that new branding can give a youthful glow to decades-old ideas" as anything but funny?
- me_bx 11y agoThese guys should make their site's even text smaller, thinner, and lighter in color. For the moment, we still notice that there's something that we're supposed to read. http://contrastrebellion.com/ http://contrastrebellion.com/ Sorry for the rant, that's the final straw...
- kbenson 11y agoGiven the context, it may have been intentional.
- me_bx 11y agoindeed :) Care has even been taken to include the light and bold variants of the font, but not the regular one.
- kristopolous 11y agoOn wow, those were words there. I thought it was just an abstract pattern of grey noise. Pity. I'd really like to know what the person is trying to say. They are using the same template as this group: http://opengrok.github.io/OpenGrok/ http://opengrok.github.io/OpenGrok/ ... I'd really like to meet the person who made this - I bet he can see through walls. (it's here: https://github.com/orderedlist/minimal https://github.com/orderedlist/minimal) might as well plug my site: http://unreadable.website http://unreadable.website
- deleted 11y ago[deleted]
- jkot 11y agoI dont see any problem... :-) https://imgur.com/zzk4iN0 https://imgur.com/zzk4iN0
- bliti 11y agoI'm not one to complain much, but it is unreadable. My tired eyes were not happy with their decision. May I suggest something more readable to the people behind the website? Please and thank you.
- amyjess 11y agoI lost it at "renaissance of artisanal protocols".
- deutronium 11y agoI like the irony of serving the message via TCP
- corysama 11y agoFrom their twitter account (https://twitter.com/notcp https://twitter.com/notcp) > Sign the manifesto: http://notcp.io http://notcp.io . If you can figure out a way to sign it using UDP, let us know. It's pretty clear they know they are being ridiculous. That said, it is nice to have reminders that there are alternatives to the overwhelmingly popular default. Kids these days grow up using TCP so much they become devs who can't conceive of whole categories of software that don't happen to line up with the tradeoffs designed into TCP. Heck, seems like most people have a hard time remembering that there's more to the Internet than HTTP.
- takeda 11y agoI personally prefer it to being that way. UDP while is very simple from design point of view is actually very complicated to use if you plan to do something more than just send few packets. The issue is primarily, that you don't have a feedback loop that tells you the rate at which you should send the data. Also badly written applications that use UDP can create congestion collapse in a network (no congestion control/avoidance).
- eloff 11y agoAeron from Martin Thompson of mechanical sympathy fame uses a custom, reliable protocol over UDP to achieve much lower latency than is possible with TCP solutions. There seems to be a growing awareness that one-size fits all protocols like TCP don't necessarily offer the best tradeoffs, even when you need reliability. https://github.com/real-logic/Aeron https://github.com/real-logic/Aeron
- gtrubetskoy 11y ago"UDP" would have been a better name than "NoTCP". (Because non-TCP would also include ICMP, for example). Also, why not just go to IP, rather than UDP? Much more flexible than UDP and even more efficient.
- wnevets 11y ago>Oh yes indeed. Just as Node.js and NIO proved to the world that bare-metal performance is always worth the consequent unreadable code aww someone is complaining about javascript/node again, how cute.
- kstrauser 11y agoI couldn't agree more. TCP is wonderful when you need it, but you very often don't need it (and pay a heavy price for features you don't need). I wouldn't want to write HTTP over UDP, but neither would I want to send telemetry data ('{"timestamp":343821902, "value": 43}') over TCP. UDP is brilliant for systems where you're more concerned about tracking the current state of things than accurately replaying the last n set of transactions.
- mholt 11y agoWell, there's QUIC, which serves HTTP over UDP. But I see your point, and you're correct. TCP and UDP have different advantages (at least for now).
- dtech 11y agoHowever, QUIC provides a lot of the features TCP has but very fine-tuned for HTTP. This is fine, HTTP is probably the largest layer 7 protocol on the internet, but if you were to design a layer 7 protocol that needed a lot of the features that TCP provides it would be quite dump to reimplement them yourself on top of UDP.
- lechuga 11y agoDisagree. In most cases you want TCP. Rarely do applications gracefully deal with loss.
- kstrauser 11y agoThat's completely dependent on the application. SNMP over TCP would be a net loss because 1) it doesn't buy you anything as SNMP doesn't have any requirements that TCP meets above what UDP provides, 2) TCP would be exceedingly expensive, requiring connection buildup and teardown, ACKs, etc., and 3) it's way easier to implement UDP than TCP, so dumb devices basically need to only construct a single Ethernet frame to make it work. Many, many applications deal much better with loss than they do with delayed retries. You don't want a VOIP app to perfectly recreate what the other part said 30 seconds ago, games usually only care about current state, and so on. In many of those cases, TCP is the wrong choice but a lot of people use it out of familiarity. Remember, UDP came after TCP. One isn't "better" than the other and they serve different requirements.
- peterwwillis 11y agoOnce the non-TCP protocol has been written, we'll need to make sure it's portable through corporate and ISP firewalls, so we should write an HTTP extension that tunnels the non-TCP protocol over HTTP proxies without using CONNECT, and on port 80. We'll need to patch the proxies and the browsers and the web servers, of course, but it's all in the name of a better, newer protocol that doesn't have the clunky overhead of TCP.
- wtallis 11y agoAnd at some point someone will notice that you can't do ECN with existing UDP implementations, so it'll start all over again but this time assembling the raw IP datagrams in userspace, and then that will have to be moved into the kernel to perform well...
- zokier 11y agoI thought Googles experiments have showed that this is less of an issue that what people generally think. Most networks pass UDP traffic just fine. And most failures occur early phase enabling reasonable fallback policy to TCP
- peterwwillis 11y agoMost networks aren't what you think they are. For example, most modern-day commercial firewalls more closely resemble a NAT machine than anything else. All your packets may be changed as they pass through in order to verify their authenticity and integrity once they return. And if the protocol isn't supported, it may not be passed through at all. If you want to support existing networks, it has to be either TCP or UDP. In order to support next-generation firewalls, you also have to use the OS's tcp/ip stack. In order to support typical commercial network/proxy configuration, you have to use a higher level protocol like HTTP. And this isn't even talking about the "features" of the different protocols and how they're handled. A replacement for TCP has to be done by a standards body and accepted by vendors, or [at least] half of the world will never be able to use it.
- hueving 11y agoHoly shit this trolled me hard. I was raging reading about how people were too dumb to understand how to handle TCP failures but were apparently smart enough to re-implement re-ordering and error recovery in their own manner. Well done.
- golanghacker4 11y ago"Oh yes indeed. Just as Node.js and NIO proved to the world that bare-metal performance is always worth the consequent unreadable code" Node.js is hardly bare metal and non-blocking IO is hardly new; Unix programmers have been writing select()/event-loop and poll()/epoll() servers for decades. The presentation of this false dichotomy between Node.js representing "bare-metal" at one end and readable code at the other suggests the author is some type of opinionated Ruby/Rails hipster programmer upset that his pet language and framework is falling out of favor, and in no small part because of its abysmal performance.
- AceJohnny2 11y agoI'm not sure, but I think the author was being sarcastic? I mean, I can hardly imagine "node.js" and "bare-metal performance" being in the same phrase and not being sarcastic.
- golanghacker4 11y agoNo, I think the author genuinely views Node.js/NIO as a bad performance/readability trade-off that was over-hyped and inferior to other existing platforms.
- EdwardDiego 11y agoWell, they're right that NIO code is pretty low level and hard to read. But then, 95% of Java devs won't need to touch NIO, they'll just use Netty which does all the NIO for them.
- toolz 11y agoIt seems like you have to be really bitter about some framework wars to pull this from that article.
- jessaustin 11y agoWhy the hell is wnevets' comment flagged? Does this just happen automatically when enough downvotes pile up? If "flagged" is a separate thing for really objectionable stuff then it doesn't make sense in this case.
- wnevets 11y agomy comment was flagged? hmm.
- jessaustin 11y agoYes the "how cute" comment is still displayed to me as "[flagged]", as well as being completely grayed out.
- jessaustin 11y agoOh this is nice. Simple points of order concerning HN operation are downvoted now? (Hint for drive-by downvoters: if you don't know what we're talking about, you probably have "showdead" set to "no".)
- wnevets 11y ago>you probably have "showdead" set to "no".) I did but I can still see my comment as normal.
- jessaustin 11y agoOpen the page in an incognito tab, so HN won't know who you are. (or log out if you prefer) I expect that your original comment will no longer be visible. This appears to be similar to the hellban functionality, in that it's hiding from you the fact of flagging this one comment. Although I have no problem with the use of hellbanning, I don't see how the behavior we see here, with respect to a mildly sarcastic response to more strident sarcasm in TFA, could be considered a good thing. Hmm, maybe I'll write a Chrome extension to remove this misfeature.
- derefr 11y agoYes, this is a joke, but it's a ha-ha-only-serious kind of joke. A rhetorical question: if other protocols are better at this or that, what forces have made TCP the only transport protocol of note for so long? Well, in TCP, window scaling needs to be OS-global to avoid flapping. This means TCP lives in the kernel. And this means, if you want a protocol with any property similar to window scaling, it also needs to live in the kernel. Which is to say, if you want your protocol to do anything that requires machine-level resource pooling, it has to be machine-global, not app-local. This is true trivially if your protocol wants to live in layer-4; anything peer to TCP or UDP has to have its own kernel driver in every major OS, and in every major firewall/load-balancer/NAT appliance. But even when you build on top of UDP on "layer 4.5", you're still under the same constraint. Even if you're not in the kernel, you still need a single-instance-per-machine daemon or somesuch. You still need to install something as root. The 1993-era user story of "my ISP just told me to enable something called NetBEUI!?" still applies. The reason much of this will be decreasingly relevant? Unikernels. If your app has guaranteed 1:1 ownership of a "machine", then your app can speak whatever wire protocols it likes; an app-level resource pool is a global resource pool. Unikernels talking to other unikernels can easily make use of new layer-4 protocols. That's exciting! Combined with the coming wave of "cloudlets" (small VMs paired to an individual customer of a device manufacturer or ISP, where the customer's mobile devices and home network use the cloudlet as a featureful VPN proxy), these new layer-4 protocols can be tunneled out to customers, too, avoiding any and all intervening muck. The next 10 years of networking will be interesting!
- zokier 11y agoSo how does QUIC solve the problems you mention? Afaik it does not require any kernel-level code.
- KaiserPro 11y agoit doesn't. QUIC is a slow inefficient toy protocol. mainly as a tunnel for accepting spdy, a protocol "designed" with TCP in mind. http://www.connectify.me/blog/taking-google-quic-for-a-test-drive/ http://www.connectify.me/blog/taking-google-quic-for-a-test-... things might have improved, but over slow lossy links, its really not worth the hassle. the OC alludes to the point that UDP requires less kernel intervention, which means you can do more funky things.
- nosideeffects 11y agoI don't know if the actual post is funnier, or the fact that this is just satire went over so many people's heads.
- deleted 11y ago[deleted]
- jchrisa 11y agoIf you like the idea of REST over UDP http://coap.technology/ http://coap.technology/ has been around a while, seems to have traction.
- verbatim 11y agoWhat ever happened to SCTP, anyway?
- wmf 11y agoIt was designed by telcos for telcos; I don't know if they ever got around to using it. It can't be used in the normal Internet because it doesn't pass through NATs.
- noselasd 11y agoYou interact with it every day if you use a cell phone. The control plane of the nodeb/enodeb(or "cell towers") and further into the core network in UMTS/LTE is using SCTP. Control messages for voice calls and SMS is carried a top of SCTP. Control plane interconnect between carriers for roaming is done over SCTP. (Though there's still plenty of gear still using TDM or ATM)
- myrandomcomment 11y agoSCTP is used in all LTE deployments to guaranty delivery between MME and eNodeB.
- danellis 11y agoWell, it can, because it has a mapping onto UDP.
- deleted 11y ago[deleted]
- verbatim 11y agoWould this be better than using very large windows in TCP? (I'm really not sure.) Offloading the expensive ordering up to a higher layer protocol to do the same thing is not something that strikes me as an obvious win.
- jjoonathan 11y agoDoesn't TCP already implement this? IIRC there's a sliding window in which packets can arrive out of order. EDIT: Yes. https://www.youtube.com/watch?v=zY3Sxvj8kZA https://www.youtube.com/watch?v=zY3Sxvj8kZA
- KaiserPro 11y agoActually its not the ordering thats the problem per-say its "packets in flight" Each packet needs to be accounted for, and only a certain amount of packets can be unaccounted for "in flight" before TCP starts throttling back. This means the higher the latency, the lower number of packets a second can be transmitted. The problem is that making a reliable transport protocol that's also fast, efficient and plays nicely on a congested network is really quite hard. (this is why aspera can charge as much as they do for what is effectively a thin wrapper around scp.) There are a couple of ways to get fast throughput over high throughput/lossy links, the easiest is to use multiple connections. I wrote a python library that does just that. Between london and Sanfran you can expect about 12megabits a second(up to about 25 burst), with 20 concurrent connection I could get just over 150 megabits a second(I hit vpn limits then).
- phs2501 11y ago...so you'd rather implement your own congestion control, your own windowing, your own reordering and reassembly, rather than just using TCP and letting the kernel do all that for you? To send a single file? And hopefully this self-made congestion control cooperates with the rest of the traffic on your connection. It doesn't sound to me like your use case would buy you much over TCP with selective ACK. Either way you have to resend dropped packets and ultimately reorder things. For a use case like HTTP/2 with multiple "channels" I could see a reason to avoid head-of-line blocking (though I'd rather just use SCTP), but for a single file?
- tcgarvin 11y agoThere is no better way to get to the top of HN than by writing something so deadpan sarcastic that all parties think you're secretly on their side.
- pyre 11y agoNotably, ICQ was implemented over UDP, though IIRC they basically implemented most of the features of TCP on top of UDP when creating their protocol.
- snowy 11y agoFrom Article: "are you serious? Oh, absolutely. There are plenty of successful, purpose-built protocols that used UDP before it was cool: DNS, NTP and RTP, to name a few." DNS and NTP are built over UDP because they are light weight applications. RTP is built over UDP because you don't care about loss. Hell even DNS still uses typically uses TCP when doing zone transfers between DNS servers because of the amount of data involved. What point is the author trying to make with this statement?
- zw123456 11y agoOne serious argument for using a connectionless protocol is mobile. The reason is that mobile networks have a MAC/RLC layer (talking 3G/4G here, e.g. LTE) and those layers have ARQ (in other words retrans). At times, those re-trans can spike (sudden Signal drop for example). That will blow the RTO on TCP and you get needless TCP retrans. This is where you have to competing retrans mechanisms flapping. The obvious fix would be for the mobile operators to terminate the TCP flow at the base station and use the Hybrid ARQ mechanism, although that could happen eventually, but would mean a lot of re-design for them i.e. cost. So if your app is going to be on mobile, it might perform better using a connectionless protocol depending on the situation.
- jjar 11y agoI read this as Not CP...
- fegu 11y agoabou Quic: "you probably haven't heard about it". Gives the true condescending hipster feel :)
- StephenFalken 11y agoA bit of UDP history by its creator [1]: Actually, UDP was "un-designed" by me and others.By this I mean that UDP was the final expression of a process that today we would call "factoring" an overcomplex design. Originally, the ARPANET end-to-end protocol NCP was a "kitchen sink" oriented toward providing remote teletype-centric access using the "telnet" protocol and the "FTP" protocol to remote machines over a packet network. A group of us, interested in a mix of real-time telephony, local area networks, distributed operating systems, and communications security, argued for several years for a datagram based network, rather than a virtual circuit based network. The group involved me, John Schoch and Yogen Dalal of Xerox PARC, Danny Cohen of ISI (now at Caltech, I think), and Steve Crocker, with Jon Postel as a supporter, and Vint Cerf and Bob Kahn as neutral referees. UDP was actually "designed" in 30 minutes on a blackboard when we decided pull the original TCP protocol apart into TCP and IP, and created UDP on top of IP as an alternative for multiplexing and demultiplexing IP datagrams inside a host among the various host processes or tasks. But it was a placeholder that enabled all the non-virtual-circuit protocols since then to be invented, including encapsulation, RTP, DNS, ..., without having to negotiate for permission either to define a new protocol or to extend TCP by adding "features". [1] "udp and me" http://www.reed.com/blog-dpr/?page_id=6 http://www.reed.com/blog-dpr/?page_id=6
- eternalban 11y agohttp://pouzinsociety.org/images/Is_the_Internet_an_unfinished_demo_-_Meet_RINA.pdf http://pouzinsociety.org/images/Is_the_Internet_an_unfinishe...
- chetanahuja 11y agoExactly. For those of us who like to play around with protocols over the real Internet, availability of UDP as basically a proxy IP protocol is a godsend. Well what really matters is that a few uses of UDP over the internet are well established (DNS, VOIP etc.) and that makes it hard for ISP's and middle-boxes to block arbitrary UDP ports. And that makes UDP the perfect conduit to invent custom protocols.
- TEMPLEOS_DEV 11y agoThis old chestnut. The problem is you end up recreating TCP to do anything useful and your "artisanal protocol" written using UDP has subtle vulnerabilities. It's only a matter of time before someone uses it for this year's amplification attack.
- eeZi 11y agoTCP has an advantage over UDP which hasn't been mentioned yet in this thread: it effectively prevents source IP spoofing. This is a huge issue for some UDP-based protocols, since it allows an attacker to send a packet with a spoofed source IP address. The response is then sent to that IP address. Protocols like DNS and NTP, which send large answers for comparatively small requests, can be misused for DDoS attacks this way (amplification).
- kazinator 11y agoThis is only an advantage of TCP over raw UDP per se. Of course, the idea is that you don't use raw UDP, but you build some session layer over it. The UDP server won't reply to a spoofed client because the packet doesn't validate. For instance, the session could be encrypted (with proper integrity checks) and the spoofer doesn't have the session key. In fact, UDP servers typically handle a large number of clients with a single socket. So each `recv` system call on the UDP socket pulls a message from a different client. The source IP and port number could be used to do the basic matching of the message to the client, but then subject to more checks. This can end up being more robust than TCP. TCP can be subject to IP spoofing, and because it doesn't have the crypto, this spoofing can interfere with the session (a form of DDoS): e.g. inject bytes into the TCP stream, which then screw up the stream so that it has to be scrapped and reconnected. A UDP based protocol can robustly drop garbage, so that the session is not affected (except for the network and CPU usage of these spoofed packets).
- rudolf0 11y agoQUIC, Google's experimental TCP replacement (at least for web traffic), does in fact prevent IP spoofing. It uses token authentication instead of a handshake like TCP does. Spoofing discussion is actually the very first paragraph in its security document: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pli=1 https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...
- acomjean 11y agoThat and TCP can send more the 64k Bytes at a time. UDP is really fast, multicast! and when you get a message its all there (not a stream) . For large messages breaking them/ reassembling them into chunks is a pain.. By the time you do all the processing/ handshaking you end up back at TCP. Interestingly the size limit is around 64k and varries slightly between Solaris, hpux and linux.
- kazinator 11y agoThe only problem is: good luck getting corporate firewalls to support connection state tracking for your custom UDP-based protocol, and getting IT managers to turn this on.
- ilaksh 11y agoI think they are actually serious. And it makes sense. TCP is holding back a lot of stuff. Its a legacy thats grandfathered in and we can do better both in terms of general purpose and specific needs.
- istvan__ 11y ago"yet another hipster technology manifesto" so good content. I guess it is a good summary what is wrong with the tech industry (lots of "solutions" are abused, built for different era, etc.) and also bashes a bit on technology like node.js but not too much. Entertaining read.
- 2times 11y agoThis is the best summary of what it is, and indeed an entertaining read.
- chetanahuja 11y agoI honestly can't make out if the author is trying to be serious or sarcastic. For instance: "We follow in their Chukka-booted footsteps by challenging the comforts of the ubiquitous Transmission Control Protocol and recognizing the well-deserved renaissance of artisanal protocols built on UDP. We didn’t start this fire, we’re just calling it what it is: the NoTCP movement" I'd admit to being too dumb to parse the exact sentiment behind that paragraph. Though it does sound somewhat like sarcasm to me. Then in the rest of the paragraphs, he actually goes on to make a pretty good case of why one might want to get rid of TCP (especially from under the complex beast that HTTP/2.0 is with it's own flow-control, multiplexing etc.) For what it's worth, I wrote my own manifesto against using TCP in all cases a few weeks ago. But this one is geared very specifically towards the needs of mobile native apps. https://packetzoom.com/blog/ https://packetzoom.com/blog/
- cwh 11y agoi read this website as "not cpio"
- tylermauthe 11y agoKind of tired of the "your technology is Hipster swill" parodies. All technology is a tool, use the right tool for the job and move on.
- avodonosov 11y agoGood thing (as well as in-process TCP stack implementations). One note: text of black color would be much easier to read than this light gray.
- jwr 11y agoTiny type, disabled zoom. Hipster indeed.
- citrin_ru 11y agoIt seems to be they don't understand TCP. Indeed, TCP has drawbacks, but without studying TCP they probably repeat old mistakes and will add new ones (not present in TCP).
- facepalm 11y agoBut is it web scale?
- jokoon 11y agoI don't see the point of the joke/sarcasm. UDP has its use if you want to have real time stuff and more granular and fine-controlled data. TCP is just for larger batches. Of course UDP is useless in many cases, but it does have its uses. It looks like this is just mocking people who can't follow the "don't reinvent the wheel" rule, but why assume that all types of wheel are already invented? P2P networking needs fine control. Bare metal is not here for nothing.
- Sami_Lehtinen 11y agoTons of discussion and nobody mentioned this: https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco... Reason for using TCP is that using UDP requires application specific implementation and making it good and efficient would require more work than making rest of the software. That's why the applications only use UDP where it really does make difference. Others just won't bother.