You don't need to make up your own for this experiment. There's already a pretty old protocol that's far superior to TCP, but failed to get adoption because of network hardware dropping everything other than TCP and UDP. It's called SCTP.
As someone who has implemented various transport protocols (both standard and custom) the biggest hurdle in layering atop IP will not be the gauntlet of WAN routers, surprisingly, rather consumer NAT devices.<p>One interesting case for a particular Netgear family of routers was that, while the traffic would survive end-to-end it was not without corruption - very specific corruption which took the form of zeroing the first 4 bytes. Given this aligns with where the src/dst ports would normally be, I suspect it was being treated as TCP/UDP albeit without the actual translation path taken.
<i>What would happen if we didn't use TCP or UDP?</i><p>One would have a hard time communicating with anyone. The internet has <i>standardized</i> around TCP and UDP. There are too many devices in most paths that will not be able to handle other protocols. Replacing all the hardware on the internet would take even longer than deprecating IPv4 in my pessimistic opinion. To get around this there would have to be some significant gains of the new protocol that would warrant big expenses in every corporation and government and all the hardware manufacturers would all have to agree on implementing support and further agree on interpretation of the new RFC.
What you want is a packet socket:<p><pre><code> sock_raw = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_ALL));
</code></pre>
IP networks should forward anything, but NAT is a major problem. Would be interesting to try with IPv6.
There's also Bell Labs IL - Internet Link - used to speed up 9P links for Plan 9 over LANs. <a href="https://doc.cat-v.org/plan_9/4th_edition/papers/il/" rel="nofollow">https://doc.cat-v.org/plan_9/4th_edition/papers/il/</a><p>And this brings me to why I love networking on Plan 9. First off the dial string, net!address!service, passes the network along with the address and service port letting you easily switch protocols as needed. e.g. a program could listen on IL port 666 using the dial string il!*!666 and the client dials il!10.1.1.1!666. Second, that lets you dial and listen on any protocol from any program. If one wanted to use raw Ethernet you use the dial string ether0!aabbccddeeff. If I wanted to add a protocol like quic or a dead one like ipx/spx I just need to mount it to /net and keep the semantics the same as other services in net and any program can dial that protocol - ezpz user space networking stacks. Powerful abstraction.
It feels like the article ends with a cliffhanger!<p><i>Why</i> did a single packet of the custom protocol get through with all later packets dropped? Does anyone know?
I always assumed any TCP/UDP packets would get captured by the OS network stack in order to be sent only to the processes listening on specific ports.<p>I guess this is a security feature, since a process cannot even listen on some ports without having elevated privileges. I wouldn't expect another process being able to capture all this traffic anyway. This would also require a mechanism of sending the same stream to multiple processes (TCP listeners and all-protocol listeners).<p>But I didn't even know it was possible to capture traffic from multiple transport layer protocols using a syscall, perhaps that syscall requires elevated privileges itself..?
I think a more interesting question is: what if internet protocols and routing equipment were designed from scratch today? Besides much larger packets, I'm guessing something basic in the style of UDP would be chosen to replace HTTP to simplify query-response lookups, a much simpler streaming protocol would be chosen to replace TCP and support all the video playing going on, and those two protocols would more efficiently handle the vast majority of traffic.
It's weird to me that the definition of portable has changed from "can be moved" to "can be moved to another machine" to "can be moved to another environment" to "can be moved to another program"<p>We had the option to make every object addressable and we chose not to. Why keep sweating over it, just accept that software only works on the devs machine and ship that.