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.