[HN Gopher] A protocol for reliable notifications over a 1 bit f...
___________________________________________________________________
A protocol for reliable notifications over a 1 bit fallible
connection
Author : todsacerdoti
Score : 47 points
Date : 2024-10-14 23:58 UTC (2 days ago)
(HTM) web link (paper.wf)
(TXT) w3m dump (paper.wf)
| tines wrote:
| 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.
| nomel wrote:
| 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.
|
| [1] TCP-keepalive: https://tldp.org/HOWTO/TCP-Keepalive-
| HOWTO/overview.html
| tines wrote:
| > 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.
| DougN7 wrote:
| 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.
| refulgentis wrote:
| 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
| SonOfLilit wrote:
| 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 wrote:
| The channel is free. Repeat each bit 1 billion times and
| reconstruct the messages based on that
___________________________________________________________________
(page generated 2024-10-17 23:00 UTC)