If you want large messages just redefine the length from 16 to 32 bits.
It's been used for millions of messages per day for 25 years and hasn't been changed in a long time.
Admittedly it isn't as common as TCP and that's a shame. But it's out there, it's public, it's minimal and it makes sense.
This protocol guarantees too much. It's still a stream.
If you just keep everything in the same order, then you never have to worry about any re-ordering.
I can see why people picked streams as the one-size-fits-all-(but-badly) abstraction.
There’s a bit of reinvention needed, sure, but adding a framing layer is about the easiest task in networking. If you want a standard way of doing it, these days you can use a WebSocket.
Edit to add: oh, I see, you want reliable but unordered messages. That would definitely be useful sometimes, but other times you do want ordering. If you don’t need ordering, isn’t that pretty much what QUIC does?
EDIT: Internet being broken is also why there's a grease extension for QUIC
This generalization isn’t true at all. Streaming data over TCP is extremely common in many applications.
When you download a large file, you’re streaming it to disk, for example.
I guess you could get pedantic and argue that an entire stream of something is actually one large message, but that’s really straining the definitions.
Nowadays perhaps video streaming, which may be lossy, so TCP is not needed for it (i.e. what is now called streaming does not have the reliability requirements of the TCP streams), might transfer more data on the Internet than file downloads, but that is not a desirable technical evolution, the replacement of downloading with streaming is just a means to extract more money from those who are satisfied by such a service.
This now means that innovations based on Quic can occur
Also, the overhead of a UDP packet is 8 bytes total, in 4 16-bit fields:
- source port
- dest port
- length
- checksum
So, we can save a max of 8 bytes per packet - how many of these can we practically save? The initial connection requires source and dest ports, but also sets up other connection IDs so theoretically you could save them on subsequent packets (but that's pure speculation, with zero due diligence on my part). It would require operational changes and would make any NATs tricky (so practically only for IPv6) Length and checksum maybe you can save - QUIC has multiple frames per UDP datagram so there must be another length field there (anyway, IETF is busily inventing a UDP options format on the basis that the UDP length field is redundant to packet length, so can be used to point at an options trailer). QUIC has integrity protection but it doesn't seem to apply to all packet types - however I guess a checksum could be retained for those that don't only.
So in sum maybe you could save up to 8 bytes per packet, but it would still be a lot of work to do so (removing port numbers especially)
For most applications some re-orderings of messages don't matter, and others would need special handling. So as a one-size-fits-all-(but-badly) abstraction you can use a stream.
> Do we have any actual streaming use of TCP, with purely streaming protocol.
But to give you a proper answer: the stream of keyboard inputs from the user to the server in Telnet (or SSH).
Wouldn't each input be a single albeit too short message? But this level of granularity really makes little sense...
You can also stick your higher level messages into a structure that's more complicated than a stream, eg you can stick them into a tree. Anything you can serialise, you can send.
Of course, the downside to this is that when you don't need these strong guarantees, you are paying for stuff you don't need.
(1) zero-copy, zero-allocation request processing
(2) up to a 2x latency reduction by intermingling networking and actual work
(3) more cache friendliness
(4) better performance characteristics on composition (multiple stages which all have to batch their requests and responses will balloon perceived latency)
If you have a simple system (only a few layers of networking), low QPS (under a million), small requests (average under 1KB, max under 1MB), and reasonable latency requirements (no human user can tell a microsecond from a millisecond), just batch everything and be done with it. It's not worth the engineering costs to do anything fancy when a mid-tier laptop can run your service with the dumb implementation.
As soon as those features start to matter, streaming starts to make more sense. I normally see it being used for cost reasons in very popular services, when every latency improvement matters for a given application, when you don't have room to buffer the whole request, or to create very complicated networked systems.
Is it possible for an out of order packet to get delayed by a millisecond? A second? A minute? An hour?
Have you written code to be robust to this?
If every message is getting dropped, the set of unacked messages fills up and the connection stops accepting messages from the application, similar to TCP in that situation.
I mostly work with TCP so haven't had to deal with unreliable channels generally, but I do use a similar approach at the application level for reliable delivery across reconnects.
And due to various political & cultural & industrial lobbying, more flexible but complex on their face approaches (OSI) were rejected.
TCP meant you could easily attach a serial terminal to a stream, a text protocol meant you could interact or debug a protocol by throwing together a sandwich, an undergrad, and a serial terminal (coffee too if they do a good job). You could also in theory use something like SMTP from a terminal attached over a TIP (which provided dial-in connection into ARPAnet where you told the TIP what host and what port you wanted).
If you look through some of the old protocol definitions you'll note that a bunch of them actually refer to simplest mode of TELNET as base.
Then in extension of arguably the same behaviour that blocked GOSIP mandate we have pretty much reduced internet to TCP, UDP, and bits of ICMP, because you can't depend on plain IP connectivity in a world of NAT and broken middleboxes.
I've seen a few implementations of a reliable UDP messaging stream (using multicast or broadcast). It uses a sequencer to ensure all clients receive the correct message and order.
It can be extremely fast and reliable.
a) It added yet another area of expertise to my portfolio.
b) I did it because it was needed to facilitate another product in the company where I worked. The alternative at the time would be paying $350,000 for middleware from Vendor-X. Not acceptable.
c) Vendor-X people noticed us, loved what we did and made us a partner to resell their middleware and we've made a ton of money on deployment, configuring and consulting services.
A reliable, unlimited-length, message-based protocol.
With TCP there's a million users that throw out the stream aspect and implement messages on top of it. And with UDP people implement reliability and the ability to transmit >1 MTU.
So much time wasted reinventing the wheel.