4 ms·

I don't believe you can open a websocket directly to another user. At least without the use of a server relayer.

by dekz 16y ago

abraham 16y ago
I'm not all that familiar with the websocket specification but isn't it pretty much just TCP connections? In which case p2p would be very similari to say TCP bittorrent?
- patrickaljord 16y ago
  You can't run a Websocket server on your browser. Only a client. So you can't get p2p by definition because in a p2p network every node is a server.
  - abraham 16y ago
    Why wouldn't you be able to run the browser as a websocket server? A browser can run everything on a computer a p2p node can.
    - dekz 16y ago
      In the WebSocket spec, it only exists to open a connection to a url on a port, there is nothing about listening to a port for connections. You could open a connection to a server which can relay other websockets data, but you can't open a connection to another client. There is nothing in the spec to create a server basically.
      - abraham 16y ago
        That doesn't make any sense. The browser server just responds to websocket requests the same way a server would. The other browsers acting as clients wouldn't even need to know it was a browser just that it was acting as a websocket server.
        dekz 16y ago
        With the current spec, how would you listen for connections?
        abraham 16y ago
        The same way that websocket servers currently listen for connections. There are websocket servers in production and they have a standard way to listen for connections. All you would have to do is implement that same functionality.
        dekz 16y ago
        I don't doubt you can implement that functionality, if you were the browser. But from the specs of Websocket currently in the browser, you cannot.
- lambda 16y ago
  No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. It is basically designed to just be better than AJAX and COMET for things that need long-lived bidirectional communication between the browser and server; it is not intended to be a general purpose TCP API. You can read about it on Wikipedia: http://en.wikipedia.org/wiki/WebSockets http://en.wikipedia.org/wiki/WebSockets Read the API spec: http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/ Read the draft protocol spec that was implemented by some browsers, but later pulled due to security concerns: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... And read the current working draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...
  - abraham 16y ago
    > No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. So it is a TCP connection. It may have its own protocol on top of TCP but as long as the browsers can create TCP connections between each other then then it can be made to work right?
    - lambda 16y ago
      Yes, it is a TCP connection in the sense that it is its own protocol on top of TCP. But then again, the HTTP request that you make with an XMLHTTPRequest call also uses a TCP connection; however, the mere fact that it creates a TCP connection doesn't mean you can implement a web server using XMLHTTPRequest. The key is that websockets are limited in what they can do; the API and protocol are fundamentally designed in such a way as to make peer-to-peer communication impossible. It opens up possibilities that XMLHTTPRequest does not, but it does not allow you to do everything you could do with raw socket access. There main reason it is impossible to do peer to peer with websockets is that you can't listen for incoming websocket connections using the websocket API; you can only initiate outbound connections, which connect to a server not written in a browser, as there are no APIs in the browser for listening for inbound connections.

I don't believe you can open a websocket directly to another user. At least without the use of a server relayer.

by dekz 16y ago

I don't believe you can open a websocket directly to another user. At least without the use of a server relayer.

I'm not all that familiar with the websocket specification but isn't it pretty much just TCP connections? In which case p2p would be very similari to say TCP bittorrent?

patrickaljord 16y ago
You can't run a Websocket server on your browser. Only a client. So you can't get p2p by definition because in a p2p network every node is a server.
- abraham 16y ago
  Why wouldn't you be able to run the browser as a websocket server? A browser can run everything on a computer a p2p node can.
  - dekz 16y ago
    In the WebSocket spec, it only exists to open a connection to a url on a port, there is nothing about listening to a port for connections. You could open a connection to a server which can relay other websockets data, but you can't open a connection to another client. There is nothing in the spec to create a server basically.
    - abraham 16y ago
      That doesn't make any sense. The browser server just responds to websocket requests the same way a server would. The other browsers acting as clients wouldn't even need to know it was a browser just that it was acting as a websocket server.
      - dekz 16y ago
        With the current spec, how would you listen for connections?
        abraham 16y ago
        The same way that websocket servers currently listen for connections. There are websocket servers in production and they have a standard way to listen for connections. All you would have to do is implement that same functionality.
        dekz 16y ago
        I don't doubt you can implement that functionality, if you were the browser. But from the specs of Websocket currently in the browser, you cannot.
lambda 16y ago
No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. It is basically designed to just be better than AJAX and COMET for things that need long-lived bidirectional communication between the browser and server; it is not intended to be a general purpose TCP API. You can read about it on Wikipedia: http://en.wikipedia.org/wiki/WebSockets http://en.wikipedia.org/wiki/WebSockets Read the API spec: http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/ Read the draft protocol spec that was implemented by some browsers, but later pulled due to security concerns: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-... And read the current working draft: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketproto...
- abraham 16y ago
  > No, it's not a TCP connection. It is a persistent, bidirectional communication channel, initiated by the browser, which uses its own protocol on top of TCP. So it is a TCP connection. It may have its own protocol on top of TCP but as long as the browsers can create TCP connections between each other then then it can be made to work right?
  - lambda 16y ago
    Yes, it is a TCP connection in the sense that it is its own protocol on top of TCP. But then again, the HTTP request that you make with an XMLHTTPRequest call also uses a TCP connection; however, the mere fact that it creates a TCP connection doesn't mean you can implement a web server using XMLHTTPRequest. The key is that websockets are limited in what they can do; the API and protocol are fundamentally designed in such a way as to make peer-to-peer communication impossible. It opens up possibilities that XMLHTTPRequest does not, but it does not allow you to do everything you could do with raw socket access. There main reason it is impossible to do peer to peer with websockets is that you can't listen for incoming websocket connections using the websocket API; you can only initiate outbound connections, which connect to a server not written in a browser, as there are no APIs in the browser for listening for inbound connections.