Hi,
I was in the middle of developing a PHP chat that stores the messages and user sessions in text files when I learned about socket.io and I would like to switch to this method instead because seems to save CPU usage on my server (currently I have to do GET requests of the php files to load messages and users every 2 seconds).
My question is, are the messages stored somewhere with socket.io? How about the user sessions with their data such as username and profiles? I get all that from a database via PHP as of now and then store it a temporary text session file.
Thanks.
are the messages stored somewhere with socket.io?
No: Socket.io is just a WebSocket library. It's your responsibility as an application developer to use socket.io to receive incoming messages which runs your own code that loads or generates responses and vice-versa. So asking that question is like asking "are the messages stored somewhere with PHP?".
How about the user sessions with their data such as username and profiles?
Again, socket.io is just a library for using WebSockets. It does not have any user or profile management features built-in. It's your responsibility to build or integrate that into your NodeJS code which then uses socket.io
I get all that from a database via PHP as of now and then store it a temporary text session file.
You'll need to keep on doing just that (though you should also store the chat messages in your database too, as using text files won't scale to more than a handful of concurrent users).
Note that unlike PHP websites, NodeJS applications do have semi-persistent, in-memory state (so you can load data from your database and use it in-between requests instead of reloading everything for each new page request or websocket message) but remember that that state will be lost when the NodeJS server shuts-down, crashes, or is killed by your web-host's management infrastructure. Also when you do eventually scale to multiple server instances each one is isolated from each other, so their in-memory state won't be shared. If you absolutely need to share some kind of low-latency (but not in-memory state) then consider using something like memcached or Redis).
Related
So I want to create some sort of anonymous chat application. The model includes a single server (centralized) and multiple clients.
The server takes no records of the chat and also no records of who has connected amd such to maximise privacy the messages are also encrypted. You get the idea.
Now, my question was: say someone sent a link to a warez site or something deemed somewhat questionable or outright illegal. Who would get into trouble? The server owner or the client? Take into account that the server only provides a means to communicate between clients and holds no information other than the brief time it needs to receive and send.
Same thing with bots connecting to the server and using it for a communication portal for a botnet.
Thanks in advance.
I want to start to create a website which is opened on a mobile phone (any kind of smartphone). This website will have the feature to control a website you have already opened on your computer. (The Volkswagen New Century Beetle from 2011 had the feature, that i could scroll via smartphone on the website opened on my desktop computer)
We have a streaming website for horsevideos, and this will be an awesome feature for our customers, if they could watch the streams on their smart tv and control via iphone/android/wp.
Also wilmaa.com from switzerland provides a remote control for smartphone to navigate on my website on smart tv/webbrowser.
Because I need a starting point to learn how it works i was checking Google, maybe there already any remote controls outside, but unfortunately i couldn't find anything.
Maybe Stack Overflow can help me by giving some starting points on how to realize this.
To do this you need some kind of 'pushing' service able to overcome the inherent drawback of HTTP that it has always been a 'pull only' system - client initiates a request, server answers. In this case you want to push an event from the server to the client.
For the past years this has been done with so called 'long polling'. This means that you 'abuse' the mechanism present in browsers that protects the server from hanging requests, but allows them to take a while. Apache is by default configured to allow a request to last 300 seconds on most platforms. Long polling works by sending an Ajax request, and if the server has no data, instead of sending that back it just waits, until either it does have data, or a long period such as a minute has expired. The client does not send a new request until it has received a response. This gives the illusion to the end user of real time feedback, and is how sites like Facebook et al have done this for years.
Since a few months it's also possible to employ a new HTML5 technology that now has stable implementations on all major browsers: Websockets. This technology allows a server to upgrade a common pull request to a full bidirectional connection, allowing realtime communication between browser and server. Regrettably, the 'regular' webservers such as Apache are not really built for this kind of logic, although it is possible to emulate it with frameworks like Ratchet. For the realtime part of the system the current platform of choice for most sites, including Stack Overflow here, is node.js - serverside asynchronous Javascript.
What I would recommend in your situation:
Set up a separate node.js server as an event dispatcher (you can get a cheap micro sized EC2 instance at Amazon for like $15 per month which will probably suffice, and is very scalable)
Keep all the other code in the regular environment where it is now, just add logic to communicate with the event dispatcher
Deploy Socket.io as your websocket handling service. It simplifies all the Javascript logic on both server and client side, and wraps a realtime connection in such a way that it's even compatible with IE5.5, by gracefully degrading towards technologies that are supported by both server and client - websockets on recent browsers, long polls or other technologies on legacy systems.
With this solution you can easily implement, with relatively little code, a system with full realtime responsiveness across multiple platforms as you described.
As for the controlling app itself, just use HTML5, with Phonegap if you intend to distribute to app stores.
I am trying to make a simple chat-like application where each of the users share data. I need to somehow update all the clients with the new data in real-time when 1 of them is sending something.
Is there a way to do it, maybe a webserver or smt ? something that works on apache?
For the client page i am using ajax to send data to server and PostgreSQL database to store the datas, but idk how to 'tell' clients that they need to 'refresh' the client browser because 1 client sent new datas to server.
Thank you in advance, Daniel!
I don't know what technology you are using so I would just recommend have a look at this service http://pusher.com/. They are a paid service that gives you the functionality you need. If you give more information on your technology we could provide better help.
I am developing a feature in my app where I need to store the state of a particular series of actions between 2 users, just like an ajax based chat service.
The scenario is as follows:
A user can is able to see which other users are online and then challenge one of them. The other user receives the challenge and accepts it. Now both the users are given 5 questions each and the match starts simultaneously for them (almost simultaneously) Then as a user navigates thru the question or solves it, the state is updated on the other user screen as well.
Essentially this is very similar to a chat system like say facebook chat. I am able to see who all are online. I send a chat msg to my friend who can then respond to that and that response is seen on my chat window.
I believe all this can be achieved by using ajax. I can easily make ajax calls to .asmx webservices and retrieve objects for a particular user as Session can be accessed there. However, I am wondering where to maintain state because session is for a particular user and I want my particular object to be accessible for two particular users.
Where do I store the state? Or taking the example of Ajax based chat, where should I store what message User1 entered and when Uer1 entered how is it shown to user2?
I was thinking application object but read it is not recmmended.
What do you recommend for such a thing?
If you're trying to do "near real-time" message passing you might want to take a look at HTTP polling (a.k.a. long polling). I won't use SQL for temporal message passing and short-term state transitions like I've seen in the past. If running on a single web server just keep the state in session or in the ASP.NET Cache. If running on multiple web servers take a look at distributed caches like memcached, Velocity (Win 2008), or NCache. Then serve the cached data to the AJAX requests which are sitting and waiting (because of long-polling). The key design issue is the design of the cache keys (no pun intended), which would need to include the user's ID for user-specific event data.
P.S. There are frameworks for large-scale, near real-time message distribution that solve scaling issues which are hit when hundreds of clients are participating in long-polling at the same time. The broad name for those frameworks are 'Comet', and they are most useful when broadcasting the same messages to many clients.
I want to be able to synchronize several text files on a user's PC in real time from my web application. Basically I want a few data files on the local PC to mirror the state of a user's data in my web application so if the web application or the user's internet connection is lost he can use those data files to get some critical info (possibly using html/javascript code stored in with those files that would run in offline mode on those data files.)
I know that google gears has a lot of interesting tools for working with offline state, but I'd prefer an even simpler application in html/javascript that wouldn't be as reliant on google gears. I'd rather use google gears to just create those files and slowly keep them in synch with the web application's version of data throughout the day.
Update on answers:
PersistJS is a good suggestion I will look into, but I was hoping people would direct me towards really good Google Gears tutorials resources.
You can save data on the browser using PersistJS, which uses the best client-side persistent storage mechanism it can find, supporting:
Flash
Google Gears
HTML 5 storage specs
browser-specific extensions
cookies
When your app reconnects, you can resync. Creating and reading text files is something the browser will generally block your web site from doing.
Risking of stating the obvious; if you want to store user state locally, isn't cookies the standard way?
maybe more then one cookie will be needed, but that sounds like the simplest of ways.
You're going to need to make an ActiveX control and a FireFox plugin to get these permissions. Short of that I agree with orip try using PersistJS
You can ask the user to download a subversion client that is predefined to interface with your subversion server only. Then write your web application to interface with the subversion service from your side only.
There is a good deal of security harm associated with granting access to a user's file system so you will want to lock down all possible points of exploitation. You will want to ensure that the user cannot access the subversion server except through the client that you ask them to install. You will want to ensure the connection between the application server and the subversion server is extremely secure so that the transmission path cannot be compromised and that malicious logic that may be loaded onto the application server cannot access the subversion server. I would say to encrypt the transmission path between those two servers and put the subversion server behind the firewall separating your network DMZ. I would also suggest use a challenge/response mechanism between the application server and the subversion server to prevent malicious code from appearing to be legitimate decisions made on the application server. Also, ensure that data only flows form the application server to the subversion server in a unidirectional fashion only, because if there is malicious logic planted on your application server then any data that comes from the subversion server is compromised without even accessing that server.
you could use the File System Object FSO through javascript, however it is dependant on Microsoft as it is an ActiveX control, it would also require permissions in the browser, or perhaps a HTA (HTML Application).
http://www.webreference.com/js/column71/
Its a real security issue so most avenues are closed down inhrentley.
Inherently the web model was designed not to authorize upstream from server to client. Now things are changing slowly maybe could you do this with Websocket ?