Is there any possible way to have browsers communicating to each other over lan/wan without the use of a server (direct peer-to-peer)?
Looks like there may be hope on the horizon: http://www.w3.org/TR/webrtc/
Yes you can try http://httprelay.io with the AJAX calls. It is simple as that:
* Send data: POST https://demo.httprelay.io/link/your_secret_channel_id
* Receive data GET https://demo.httprelay.io/link/your_secret_channel_id
IIRC, Opera released some kind of addition to their browser that embedded a webserver for just that functionality:
http://unite.opera.com/
Not sure it really went anywhere, but I think its time will come.
In pure HTML/Javascript? Probably not.
To my knowledge, there's no good way in native JavaScript to listen for connections. In HTTP, the client opens a port, sends a request, and receives a response. You could use the XHTTP or similar class to make a request but there's no good way within a normal web page to create a server on the other end that would listen for requests.
Given that, I know that Flash provides a socket library that allows you to listen for connections. (I imagine Silverlight does this as well, though I haven't researched it.) If you were to create an object using either of these technologies, you could listen for connection requests from any client (assuming that you're not behind a firewall or some other connection-filtering device), maintain an open socket and send whatever you want over the wire.
Summary:
Probably can't do this in JavaScript/HTML/CSS.
BUT, you could pull it off in Flash or Silverlight.
If the browsers are behind firewalls you can look at using NAT traversal.
Protocols like STUN and TURN are used by WebRTC to do this.
This web site has some nice examples/tutorials HTML5 Rocks
Short answer: Nope. Not possible.
Long answer: You could write a signed java applet that implements a web server in each browser. Then browser "a" could talk to browser "b's" applet (don't' close that tab!). You would then have limited access to the others browser state in this way.
Similarly, you could write a plugin/addon that could accomplish much of the same thing.
The real question is why would you want to do this? what are you trying to accomplish? Answer that question and we might be able to come up with a solution.
Yes, they could, but they would need to be designed to establish the connection (or would need to have a module that does it).
Even if I'm wondering why would they need to..
Flash - Stratus. New stuff in latest flash that provides P2P connections.
Related
I want to make an browser based chess game. Where 2 users take turns making moves on the same board.
At the moment I've set in motion a tomcat server with spring that picks up rest calls made by the node server.
However I'm making a rest call every time any user makes a move. Although the response happens very quickly as there is very little to be done on the server side.
But I feel this may not be the best approach. Is there a better alternative or would rest calls be sufficient in this scenario?
You can use the websocket.io with nodejs for the real-time communication between users.
If you don't want to use the server at all then you can use the webrtc that uses peer to peer connection.
Here are few useful references:
https://dev.to/rynobax_7/creating-a-multiplayer-game-with-webrtc
https://rynobax.github.io/jump-game
https://github.com/jwagner/webrtc-pong
https://www.webrtc-experiment.com/#featured
For Nodejs and socket.io
https://github.com/fbaiodias/phaser-multiplayer-game
Thanks
Most examples I have seen are are just small demo's and not full stack applications and they use websocket for messaging, but for any chat application there is more data then just messages...suppose like user profile, his contacts etc.
So should I use websockets for all communication between server and client or just use them for sending messages and do other things through http? If I am to use websocket for all communication how do url design of the app...since websockets don't have have any different urls like http.
You might be interested in WAMP, an officially registered WebSocket subprotocol that provides applications with WebSocket based
asynchronous, bidirectional remote procedure calls
real-time publish & subscribe notifications
Disclaimer: I am original author of WAMP and work for Tavendo.
Pretty sure you'll get the usual "it depends" answer, because, well, it depends!
If you are going to build a large application, to be used by a number of different clients in different network arrangements etc then I personally wouldn't recommend using WebSockets for everything. Why?
It's a new standard, so not all clients support it
In some network configurations WebSocket traffic may be filtered out, meaning you end up with no communications - not great
If you end up exposing an external API then HTTP is much better fitted for the job and will likely be easier to code against. There are a lot more tools out there to help you with it and styles that everyone is familiar with, like REST, to follow.
Use WebSockets when you require data being pushed from the server without the client having to poll for it, or when HTTP header overhead becomes a problem. And if you still decide to use it make sure you have a fallback mechanism (e.g. longpolling) so you don't end up with no comms.
I'm afraid I can't help you regarding WebSocket API design... given it's a new standard I don't believe the community has settled on anything just yet so you'll have to come out with your own message-based scheme.
I want to monitor in real time the data that users enter in comments table.
I have an Apache server running, and suppose that has a node server on port 1337.
How would I do that every time someone save new data, eg return me the total number of table rows in comment and show it in a view?
Maybe way is to make the $this->Comment->save($this->request->data); using a different port using Httpsockect?
Yes, it is possible.
You have multiple ways of solving this, let me give you my ideas
You can simply use long-polling and don't use Node.js at all. It's a suitable solution if there won't be too much traffic there, otherwise you will have a bad time.
You can use websockets and don't use Node.js at all. Here you have a basic guide about websockets and PHP. Although, I am almost sure you won't be able to create "rooms", that is, sending notifications for specific comments.
You can also use Ratchet. This is a more sophisticated library to handle websockets and it supports rooms.
Lastly, if you want to full dive in with Node.js and CakePHP, I would suggest start by watching this talk given on Cakefest 2012 which exactly describe your scenario.
After you have watched that, you might want to learn a little about Socket.io. This is a more complex solution, but it's what I have used when integrating CakePHP and Node.js to create real time applications.
The strategy here is to have the users join a room when they visit /article/view/123, let's say the room name is the articleID, then socket.io will be listening for events happening in this room.
You will have a Cakephp method that handles the save. Then, when user submits the form you don't call directly the Cake action, you have socket.io to dispatch an event, then in your event you pass the data to the server (Node.js) and nodejs will call your cakephp function that saves the data. When Nodejs receives confirmation from CakePHP then you broadcast an event (using socket.io), this event will let know all users connected to that room that a comment has been made.
You have basically the choice between Websockets and long polling.
Websockets (with Ratchet and Autobahn.js)
Long Polling Using Comet
Decide which technology you want to use and start implementing your use case. Consider that Websockets are more or less new. Depending on your requirements you might not be able to use Websockets because you might have to support crappy browsers. See this page.
Background: I am building a web app using NodeJS + Express. Most of the communication between client and server is REST (GET and POST) calls. I would typically use AJAX XMLHttpRequest like mentioned in https://developers.google.com/appengine/articles/rpc. And I don't seem to understand how to make my RESTful service being used for Socket.io as well.
My questions are
What scenarios should I use Socket.io over AJAX RPC?
Is there a straight forward way to make them work together. At least for Expressjs style REST.
Do I have real benefits of using socket.io(if websockets are used -- TCP layer) on non real time web applications. Like a tinyurl site (where users post queries and server responds and forgets).
Also I was thinking a tricky but nonsense idea. What if I use RESTful for requests from clients and close connection from server side and do socket.emit().
Thanks in advance.
Your primary problem is that WebSockets are not request/response oriented like HTTP is. You mention REST and HTTP interchangeably, keep in mind that REST is a methodology behind designing and modeling your HTTP routes.
Your questions,
1. Socket.io would be a good scenario when you don't require a request/response format. For instance if you were building a multiplayer game in which whoever could click on more buttons won, you would send the server each click from each user, not needing a response back from the server that it registered each click. As long as the WebSocket connection is open, you can assume the message is making it to the server. Another use case is when you need a server to contact a client sporadically. An analytics page would be a good use case for WebSockets as there is no uniform pattern as to when data needs to be at the client, it could happen at anytime.
The WebSocket connection is an HTTP GET request with a special header requesting the server to upgrade it to a WebSocket connection. Distinguishing different events and message on the WebSocket connection is up to your application logic and likely won't match REST style URIs and methods (otherwise you are replication HTTP request/reply in a sense).
No.
Not sure what you mean on the last bit.
I'll just explain more about when you want to use Socket.IO and leave the in-depth explanation to Tj there.
Generally you will choose Socket.IO when performance and/or latency is a major concern and you have a site that involves users polling for data often. AJAX or long-polling is by far easier to implement, however, it can have serious performance problems in high load situations. By high-load, I mean like Facebook. Imagine millions of people loading their feed, and every minute each user is asking the server for new data. That could require some serious hardware and software to make that work well. With Socket.IO, each user could instead connect and just indefinitely wait for new data from the server as it arrives, resulting in far less overall server traffic.
Also, if you have a real-time application, Socket.IO would allow for a much better user experience while maintaining a reasonable server load. A common example is a chat room. You really don't want to have to constantly poll the server for new messages. It would be much better for the server to broadcast new messages as they are received. Although you can do it with long-polling, it can be pretty expensive in terms of server resources.
so I have this TCP connections between my server and client, and anyone can connect to my server. But I want to make sure that the client is really using MY client application and not just faking messages from a fake TCP client. What would be the ways to do that, check that the connection really is from my game client?
Thanks!
EDIT
If I'm gonna use TLS, can I solve that problem?
There will probably not be a complete solution to your problem, since whatever you do, the other party might always take your program, run it in a monitored environment, manipulate the runtime data and let it use its "secure" network protocol. Since the client application is in uncontrollable hands, you can never be sure that it is your own program.
Baby example: My application runs your application and plays back the data to your server, and forwards your response back to the application. How can you tell?
That said, it might be a very promising "99%" approach to use SSL and hardcode the client's private key into the application -- with some trickery you can try and make it hard to find (e.g. see how Skype does it). If you then also build integrity checks into your program that figure out whether anyone is manipulating the memory or debugging into your program, you can try and make it a bit harder for a potential adversary. (But note that you will always have to ship the private key with your application, so it isn't really safe from discovery.)
Others have suggested useful answers to your question, but I'm going to suggest another approach. Re-examine your requirements.
Ask yourself why you want to know the identity of the client program. Is it so that you can trust your client program more than you trust 3rd-party client programs?
If you need to trust the identity or integrity of software that you have already shipped to your customers, I claim your security model is broken. Once the software runs on a client's PC, you should assume it is evil, even if you originally wrote it.
Any status, any command, any data whatsoever that comes from the network must be checked before it is relied upon.
My default response is to use a challenge/response authentication.
After connection, send a random number from the server to the client
The client then computes, using a hash/key/.... a response message and returns that to the server
If the response matches the servers computation, your chances of authenticity are better. Note though that a reverse engineer of your client will leave this method open to fraud.
You could use a public/private key pair in order to verify that you are who you say you are.
http://en.wikipedia.org/wiki/RSA#Signing_messages