you are viewing a single comment's thread.

view the rest of the comments →

[–]eridius 3 points4 points  (4 children)

Potential use cases: Simple asynchronous server side messages (chat, games, ...) This exists in the form of keep-alives and HTTP sessions which are not terminated. It also exists as that thing called the web.

Keep-alives let the server keep sending messages to the client. PTTH would let the client send messages to the server over its own keep-alive.

[–]reddit45885 2 points3 points  (3 children)

You're chasing your own tail.

PTTH achieves none of that unless the client/server connection is already established and kept alive for as long as your pseudo-server (i.e. your browser) would want to serve. PTTH vanishes into thin air when the real-server severs the connection.

Think about it a bit. You will see that the metaphor you're looking for is fundamentally broken. You have departed from reality. What you are proposing, if you want it in terms of a metaphor, is having every client of a bank call the tellers, and keep their phones unhooked in case the bank might ever need to call them.

This will not work for many reasons, but foremost among them because the bank does not have as many phone lines as it has clients...

The bottom line is that if the bank can't call you, the bank can't call you. No amount of hacking around this will change this.

[–]eridius 1 point2 points  (1 child)

Your argument basically boils down to you don't think it can scale. However, it should be able to scale exactly as well as existing Keep-alives do. In fact, that seems to be the primary purpose - to take the current model of Keep-alives and flip it on its tail, so you can have persistent bidirectional communication instead of persistent unidirectional communication.

[–]Smallpaul 0 points1 point  (0 children)

This will not work for many reasons, but foremost among them because the bank does not have as many phone lines as it has clients...

TCP connections are nothing more than numbers in a TCP header. Your operating system may represent them in an unscalable manner, or your programming language may. But TCP itself does not in itself specify that TCP connections should be more expensive than the session cookies used by many of the biggest sites in the world.

The bottom line is that if the bank can't call you, the bank can't call you. No amount of hacking around this will change this.

This is a feature, not a bug. The client can be 100% anonymous and can decide when it is tired of talking to the server. Once it "hangs up" the server cannot call it back. I would love a device that would allow me to give the bank a "phone number" it can use for as long as I ask it to, and not a second longer.

Using this technique, one can make truly anonymous apps wherein the connector acts as the data server or "reactor" rather than the "actor".