I'm experimenting broadcasting media (webcam, recorded videos -- like TV) over the internet through websocket (currently only works on Chrome). It is working fine in controlled environment.
However, when put it on test in real life environment most of the times the clients did not receive data sent from the other end.
Here's how I set my websocket configuration (for example only):
var websocket = new WebSocket('ws://74.13.452.171:8080');
websocket.addEventListener("message", function(e) {
// do something with e.data
});
So how to make sure that all clients visiting a certain page of the web site received data sent from another client.
Thanks in advance
Related
I've been using Burp Suite to do some testing on a game that uses websockets(wss). At the beginning of the connection, the server sends some basic meta data to the client(certain characters that have been unlocked, current game volume, etc.). It was my understanding that if I altered the game messages from the server prior to arriving at the client, the client wouldn't know there were changes made, but instead the connection is dropped and a new connection is established, resending the same meta data.
I imagine that there must be some client side data verification prior to loading the game and that is what is preventing the altered messages from coming through, possibly using the session token as part of the process. That seems counterintuitive since the client must then already have some knowledge of that data to do that verification. I would understand if it were the server side since things can be cross referenced, but not through the client side. What type of strategy do you think are being deployed in this type of socket connection? I haven't seen anything in regards to client side websocket message verification and wanted to know if this is a standard way to handle users trying to alter your packets.
I´m a web programmer and I'm experienced in regular synchronous and asynchronous web services. So the normal way to get data from a web server is to request it (pull it) or to establish a permanent connection.
Now I'm asking myself if there is any possibility to run this the other way round so that the server pushes new data to the client without a previous request of the client by using native technologies like HTML5 and Javascript.
Summarized: I'm searching for a way to realise a server side push system what works with any modern web browser (IE, FF, Chrome, Safari,...) by using regular technologies like HTML5 and Javascript without any plugins or additional software.
The client should just listen for new data as long as the web site is opened and the only connection from the server should happen if new data gets pushed. It must work even through NAT or Firewalls.
Well main reason is to save server load and data transfer with many connected clients. Please also mind that not each push will be a broadcast, single client push must also be available.
Is this somehow possible or still no way to handle it without extra software?
Thank you
Though it’s not implemented in all browsers yet, you can try using the standard Web Push API.
You can read more on it in the articles Using the Push API & Push Notifications on the Open Web.
The Push API is a W3C standard to let you enable users of your Web app to get push notifications at any time—even in the background; i.e., even when your Web app isn’t running in the foreground on the user’s device (or even when the browser’s not currently running on the user’s device).
It uses Service Workers to handle messages sent using common push services, and to allow your Web app to react to the push notifications it receives.
It exposes a new push event to scripts. Here’s a simple code example from the Push Notifications on the Open Web article that shows how to use that push event to show an actual notification.
self.addEventListener('push', function(event) {
console.log('Received a push message', event);
var title = 'Yay a message.';
var body = 'We have received a push message.';
var icon = '/images/icon-192x192.png';
var tag = 'simple-push-demo-notification-tag';
event.waitUntil(
self.registration.showNotification(title, {
body: body,
icon: icon,
tag: tag
})
);
});
Update 2016-02-12
The Microsoft Edge team recently moved the status of Web Push support in Edge to Roadmap Priority: High — We intend to begin development soon. Since Chrome and Firefox have already shipped support for it, that means
once Edge lands that support, you’ll be able to send standard push notifications to Edge, Chrome, and Firefox users of your Web apps.
There is WebSockets technology, it allows continuous full-duplex connection stream between a client and a server. More detailed here https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications.
WebSocket is standardized protocol and each server supports it.
I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here
I am working on a web application where I have to make live updates to the pag. When data is inserted, deleted or updated in the server-side database, then the page will be updated. I have heard about persistent connections. I have also tried AJAX using setTimeInterval(), but the major problem is that when thousands of requests are sent then the browser will start misbehaving. I need something that will make a single request and keep it open/alive and that request will exchange data between the client and the server.
You need PUSH from server, aren't you ? This is the ability for a webapp te receive notifications from the server.
There are several options depending on your server.
For example, I would recommend socket.io for node.js.
Here's the scenario, I have a client side application, served by PHP on a different server to the node.js + socket.io application. It can connect and receive broadcasts sent from the server. If the connection drops, the application falls back to polling a database (using setInterval()). It attempts to reconnect every 5 polls, and it can successfully reconnect and continue to receive messages.
My problem occurs when the user loads the page and the node server cannot be reached (I turned it off for testing), I then turn on the server and on the 5th poll, it successfully connects to the server, using socket.socket.reconnect();. However, whenever the server broadcasts messages, it doesn't fire the event. Note that this doesn't happen when testing on a phone (which falls back to a different socket method)
I have already seen the question found here Reconnection in socket.io problem in `socket.on('message',function(){})`, however, the socket has not previously been connected so I don't think it could be the session?
EDIT: I changed the socket.socket.reconnect() to socket.socket.connect() and it fixed the problem. If someone could explain the reasons of why this works I'd like to know. I know its because the server isn't actually reconnecting, but would like more info.
Thanks.
well you possibly know the reason for this. server is not reconnecting. it is actually connecting. when you tell socket.io to reconnect it searches for the previous connection handle and thats where the problem arises.