3 ms·

Thanks, but why wouldn't web sockets work with TCP hole punching? [http://www.acooke.org/cute/WhatisTCPh1.html http://www.acooke.org/cute/WhatisTCPh1.html - sel

Thanks, but why wouldn't web sockets work with TCP hole punching? [http://www.acooke.org/cute/WhatisTCPh1.html http://www.acooke.org/cute/WhatisTCPh1.html - self link, but used to be a reasonable Quora post] Is it just that no-one has done this yet? I don't see an obvious technical reason.

IgorPartola 15y ago
Does web sockets actually allow you to bind() and listen()? I do not believe so. Will take a look at your link in a bit.
- andrewcooke 15y ago
  TCP hole punching avoids the need to bind and listen. You arrange things (thanks to some looseness in the TCP spec, with the help of a central server) so that two "outgoing" connections talk to each other. It's how Skype manages to make incoming connections to computers, for example, even though they are behind NAT (firewalls and modems). [edit: for some reason I can't reply to your reply below, but you are misunderstanding how hole punching works. They do not listen - that (avoiding listening) is pretty much the whole reason why hole punching is needed/used. But the latter point about complexity is probably valid.]
  - IgorPartola 15y ago
    According to [1], section 4.2: > From the same local TCP ports that $A$ and $B$ used to register with $S$, $A$ and $B$ each asynchronously make outgoing connection attempts to the other's public and private endpoints as reported by $S$, while simultaneously listening for incoming connections on their respective local TCP ports. This makes it sound like both hosts have to listen for incoming connections: there is no way to hijack a TCP session and redirect it to a different host on the fly (aside from some very special circumstances where you have set up anycast and TCP session sharing, which you wouldn't be able to do in a network you do not fully control). Also, AFAI remember, the WebSockets API is a step above TCP: you ask the browser to make a connection to endpoint S, and it negotiates the connection by asking the server if it supports not just TCP, but WebSockets and from where, etc. Thus the example from [1] would get much more complicated: you now have to make sure the browser not only performs the normal WebSocket setup, but then makes a new connection to a different server, while simultaneously listening for an incoming connection: not something, I believe, a part of the WebSockets spec. [1] http://www.brynosaurus.com/pub/net/p2pnat/ http://www.brynosaurus.com/pub/net/p2pnat/
  - huhtenberg 15y ago
    > TCP hole punching avoids the need to bind and listen You still need a bind. This greatly improves the chances of symmetrical TCP open actually going through as planned. Also, you will need a central server to coordinate the setup, because, again, this further increases the precision of hole punching.

IgorPartola 15y ago

Does web sockets actually allow you to bind() and listen()? I do not believe so. Will take a look at your link in a bit.

andrewcooke 15y ago
TCP hole punching avoids the need to bind and listen. You arrange things (thanks to some looseness in the TCP spec, with the help of a central server) so that two "outgoing" connections talk to each other. It's how Skype manages to make incoming connections to computers, for example, even though they are behind NAT (firewalls and modems). [edit: for some reason I can't reply to your reply below, but you are misunderstanding how hole punching works. They do not listen - that (avoiding listening) is pretty much the whole reason why hole punching is needed/used. But the latter point about complexity is probably valid.]
- IgorPartola 15y ago
  According to [1], section 4.2: > From the same local TCP ports that $A$ and $B$ used to register with $S$, $A$ and $B$ each asynchronously make outgoing connection attempts to the other's public and private endpoints as reported by $S$, while simultaneously listening for incoming connections on their respective local TCP ports. This makes it sound like both hosts have to listen for incoming connections: there is no way to hijack a TCP session and redirect it to a different host on the fly (aside from some very special circumstances where you have set up anycast and TCP session sharing, which you wouldn't be able to do in a network you do not fully control). Also, AFAI remember, the WebSockets API is a step above TCP: you ask the browser to make a connection to endpoint S, and it negotiates the connection by asking the server if it supports not just TCP, but WebSockets and from where, etc. Thus the example from [1] would get much more complicated: you now have to make sure the browser not only performs the normal WebSocket setup, but then makes a new connection to a different server, while simultaneously listening for an incoming connection: not something, I believe, a part of the WebSockets spec. [1] http://www.brynosaurus.com/pub/net/p2pnat/ http://www.brynosaurus.com/pub/net/p2pnat/
- huhtenberg 15y ago
  > TCP hole punching avoids the need to bind and listen You still need a bind. This greatly improves the chances of symmetrical TCP open actually going through as planned. Also, you will need a central server to coordinate the setup, because, again, this further increases the precision of hole punching.