Hmm, I guess I expected this to be a lot more sophisticated, but it's pretty much just your first guess on how to do this. Doesn't really address the dropping of messages. I guess the author is fine with the fact that there may be an arbitrarily long (but probabilistically limited) delay between when the client wants new messages and when it learns they exist.
Given that the first channel is perfect, I think a better solution, which only requires that one channel, is what we used to do for efficient polling before we had push notifications.
1. The client makes a request to the server for new messages on the lossless channel. The server does not respond immediately. (Remember that this communication channel is perfect, so there's no need to send overhead data for timeouts or keepalives on this.)
2. When the server has new info for the client, it responds to the client's request with that info.
3. When the client gets a response, goto step 1.
This way you basically always have a request from the client blocking, and the request is only responded to when there's data to respond with. You don't transmit any unneeded information, you don't need the lossy channel, and you get the information immediately when it's available!
---
In the old days we would implement the client this way, and then have our server-side PHP code loop 60 times or so, with 1-second sleeps between each iteration, cheaply polling for new data, and responding when we found some. If you never found any new info for the client, you'd just send back an empty response, and the client would immediately ask again. With a perfect channel you wouldn't need this concession to web protocols of course, but it worked back then pretty well. You'd have a maximum of 60 "overhead"/empty-response polls per hour from the client which is not too bad.
DougN7 3 hours ago [-]
That http-polling technique works quite well. I use it to essentially stream an RDP session, within which YouTube plays and sounds just fine. Computers and the network are surprisingly fast these days. I heard once this is basically how XMPP works but I never looked into it.
nomel 6 hours ago [-]
The only possible caveat is that you might need some sort of keep alive [1] to detect if the connection has severed, because an idle channel (like with tcp) can mean an idle wire.
> The only possible caveat is that you might need some sort of keep alive [1] to detect if the connection has severed
You need this in the real world, but not with the hypothetical "infinite bandwidth perfect connection" of the problem statement. Also you'd need a keepalive/heartbeat with the author's original proposal if we want to allow real-world exigencies to start creeping in (suppose the server is very busy serving other requests and doesn't get to yours for a while), so it's not specific to the alternative I proposed.
SonOfLilit 5 hours ago [-]
Why would we ever use the obscenely expensive channel? Surely there are ways to solve this with only the single-bit channel?
Some error correction codes, some cryptographic hash checksums, and now you have a free trustworthy bidirectional bitstream.
jonathrg 4 hours ago [-]
The channel is free. Repeat each bit 1 billion times and reconstruct the messages based on that
refulgentis 6 hours ago [-]
Please don't try this at home. This is clickbait, or alternatively, a naive discussion that didn't expect top-of-HN attention.
There's one issue spelled out as a premise, namely, that this requires another connection thats perfectly 100% reliable.
Then, there's another glaring issue. I won't recap the article for this one because there's too much verbiage involved. TL;DR: fallible is assumed to mean "if the server receives a request, its guaranteed the client will receive a response". [1] shows what happens when that's not the case
Last but not least, there's a lot more to TCP than what's let on in the article. "turns out this absurd hypothetical isn't actually that far off of how TCP+TLS and UDP behave" -- I won't attempt to claim this for UDP, but I am 110% certain that this is extremely misleading for TCP. McDonald's hamburger isn't that far off from steak is significantly more accurate.
Usually I wouldn't skewer something, but, I've seen the horror of a "we'll just do the good and necessary parts of TCP" reimplementation. One that ran on 10s of millions of devices and led to crappy Bluetooth syncing and throughput for years. Two people picked the parts of TCP they thought were necessary, hacked it in, and it's hard to accept how much this cost various people and companies in various ways. 10 digit problem.[2]
[1] c.f. here for an easy trace in the article's vernacular of what happens if that's not the case https://pastebin.com/0Zs1pRfR
[2] arguably, the problem here wasn't trying it, but management being unable to handle everything after trying it. But that's a whole different story :) -- at 26 I would have thought this was impossible, at 36, I expect it
Rendered at 02:00:42 GMT+0000 (Coordinated Universal Time) with Vercel.
Given that the first channel is perfect, I think a better solution, which only requires that one channel, is what we used to do for efficient polling before we had push notifications.
1. The client makes a request to the server for new messages on the lossless channel. The server does not respond immediately. (Remember that this communication channel is perfect, so there's no need to send overhead data for timeouts or keepalives on this.)
2. When the server has new info for the client, it responds to the client's request with that info.
3. When the client gets a response, goto step 1.
This way you basically always have a request from the client blocking, and the request is only responded to when there's data to respond with. You don't transmit any unneeded information, you don't need the lossy channel, and you get the information immediately when it's available!
---
In the old days we would implement the client this way, and then have our server-side PHP code loop 60 times or so, with 1-second sleeps between each iteration, cheaply polling for new data, and responding when we found some. If you never found any new info for the client, you'd just send back an empty response, and the client would immediately ask again. With a perfect channel you wouldn't need this concession to web protocols of course, but it worked back then pretty well. You'd have a maximum of 60 "overhead"/empty-response polls per hour from the client which is not too bad.
[1] TCP-keepalive: https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
You need this in the real world, but not with the hypothetical "infinite bandwidth perfect connection" of the problem statement. Also you'd need a keepalive/heartbeat with the author's original proposal if we want to allow real-world exigencies to start creeping in (suppose the server is very busy serving other requests and doesn't get to yours for a while), so it's not specific to the alternative I proposed.
Some error correction codes, some cryptographic hash checksums, and now you have a free trustworthy bidirectional bitstream.
There's one issue spelled out as a premise, namely, that this requires another connection thats perfectly 100% reliable.
Then, there's another glaring issue. I won't recap the article for this one because there's too much verbiage involved. TL;DR: fallible is assumed to mean "if the server receives a request, its guaranteed the client will receive a response". [1] shows what happens when that's not the case
Last but not least, there's a lot more to TCP than what's let on in the article. "turns out this absurd hypothetical isn't actually that far off of how TCP+TLS and UDP behave" -- I won't attempt to claim this for UDP, but I am 110% certain that this is extremely misleading for TCP. McDonald's hamburger isn't that far off from steak is significantly more accurate.
Usually I wouldn't skewer something, but, I've seen the horror of a "we'll just do the good and necessary parts of TCP" reimplementation. One that ran on 10s of millions of devices and led to crappy Bluetooth syncing and throughput for years. Two people picked the parts of TCP they thought were necessary, hacked it in, and it's hard to accept how much this cost various people and companies in various ways. 10 digit problem.[2]
[1] c.f. here for an easy trace in the article's vernacular of what happens if that's not the case https://pastebin.com/0Zs1pRfR
[2] arguably, the problem here wasn't trying it, but management being unable to handle everything after trying it. But that's a whole different story :) -- at 26 I would have thought this was impossible, at 36, I expect it