So I have an application that uses webRTC to set up a video chat between 2 browsers. I'm using node.js for the application and socket.io to make the handshake. I have made a successful test in the chrome browser in connecting the clients so now the next step is to allow this to be used by more people.
I was wondering what would be the best way to approach the server side of creating 'rooms' and connecting two people who would like to chat. In the test I just put the one who created the offer in an object and if the second person matched the first (by UUID or a keyword) then the connection would be made but what would be a better, more secure, and more fitting method to do this with more people?
My application currently has MySQL so should I make use of a table? I feel like that would be time consuming/too much calling to a db... Should I focus more on Socket.io? Can node's socket.io handle a lot of connections to the server well enough?
If my question isn't clear please tell me.
P.S. any GOOD tutorials or articles on setting up a webRTC connection on mozilla would be great. I can add the connection but for some reason adding the stream of the one who 'creates offer' isn't being sent over.
A "room" in WebRTC will just be use for signaling, a way of sending messages before the actual connection is initiated.
"My application currently has MySQL so should I make use of a table?" - that's not exactly the best approach. If your application uses a framework/technology/etc, it doesn't mean that you should use it everywhere. You should use a technology when it answers best your needs. If such a room has to have some persistent attributes, then it makes sense to make use of a persistent storage, such as a database.
Related
I am trying to Ajax load from LAN's mysql using chrome app.
I am proposing Ajax because I need chrome app to load up any update in the SQL instantaneously.
Since this app is only used in LAN network, I presume there is no need to maintain a web server (aka running Apache). Can anyone provide some hints as this answer I found on the forum does not help me (an absolute newbie) too much.
https://developer.chrome.com/extensions/xhr
Thank you.
YY
Since this app is only used in LAN network, I presume there is no need to maintain a web server (aka running Apache).
AJAX refers to making a HTTP request to.. something.
Something that can answer HTTP requests is called a web server.
So, you do need some sort of web server. It may be a component of MySQL server, but it's still a web server.
That said, it doesn't look like MySQL has a supported HTTP interface. There is an experimental HTTP Plugin that provides REST API, but it's experimental. Therefore, you would need a separate server application that does what you need.
That said,
I am proposing Ajax because I need chrome app to load up any update in the SQL instantaneously.
AJAX is not a magic bullet. It works well for requesting data, but it is not adapted to receiving updates initiated by the server you're talking to. It's a request-response cycle, and while there are some techniques to use it to push data they are hacks.
WebSockets evolved to cover the bidirectional, persistent communication needs. However, this again would require a web server to sit as a proxy between your DB and your app - this time, WebSockets-capable.
That said, building a Chrome App allows you to connect to a database directly - since Chrome Apps are capable of using chrome.sockets API. You would need a JavaScript library specifically adapted to the task, but those probably exist.
That said, and noting that I'm not an expert on databases, but..
Databases are not designed to notify you about updates. You need to poll them to see if the data has changed. You will not get it instantaneously no matter what interface you use. You'll need to periodically monitor it for changes.
Considering this, depending on what you're trying to ultimately do you may be choosing a wrong instrument.
There's a lot of "buts" here, and it seems like a complex task. You should re-evaluate your readiness as an "absolute newbie" to undertake it.
I've been traveling for the last couple weeks and have found a issue with the method that Ajax uses to construct a website. I understand that the webpage requesting only the pieces it needs is the most efficient method for the servers but when working in an environment where signal comes and goes or is being throttled by a provider, most websites running on this model become completely unresponsive and turn every interaction into a several minute wait.
In situations where the bandwidth is limited, the best performance generally comes from websites that have all of their content on one single page that is constructed for the user before it is sent. I understand that this is not the restful way but I was wondering if there was a middle ground to this solution.
Is there a way to batch many different AJAX calls where the user would only be sending one large call to the server which then the server would compile everything that is listed and then returns it in one heap? Or is this something that hasn't been formed into a standard yet and a custom server architecture would end up needing to do?
In a situation where bandwidth is extremely limited, everything you will try to do will be a pain.
Yes, in this scenario, frequently opening connections to the server through multiple requests (which is very typical of ajax single page applications) will make the experience worst than opening one single connection to the server.
However, you need to ask yourself if you want your web application to cater to clients with fast connections or to cater to clients with slow connections and design your web application accordingly. If you make it only to accommodate slow clients then the user experience for those with faster connections will suffer and vice versa.
You could also decide to cater to both audiences by creating a version for each but it's a lot of extra work
I have no idea what your web application does. But if it's to simply "view" data then perhaps you can get away with loading all the data from the start. However, if your web application contains a lot of data manipulation features then you have no choice, stick with Ajax and get a better internet connection.
If you want to batch your requests then your web application needs to be designed that way which would allow you to do everything you need to do on the client side before clicking on a "save" button that will gather all the changes you made and send it all in 1 request.
You should always build your web application according to your client's situation. If you're traveling a lot then that might be strictly your problem and won't ever be your client's problem. In this case, stick with ajax and get a better internet connection.
If the client is yourself then heck you could do whatever you want to ease your pain including loading everything from the get go.
Unfortunately there's no magic solution.
Hope it helps!
I have a PHP/MySQL-Twilio app. I edit "templates" in the PHP app, and when a texter texts in via twilio they are served one of the templates in a text message.
Lately I've been dabbling in Node, mostly just to write little scripts, not whole applications. I think using Node for the texting interaction would be a really good idea, but I've made an assumption:
The node process would run continuously, keeping a mysql connection open. It would be faster than PHP because the connection wouldn't have to be opened and closed for each twilio request.
Is this correct? Does it make sense to rewrite this corner of my project in Node for that reason? I'm not quite ready to rewrite the whole thing.
You can open and close connections on every request if you wish, howevere connection pooling is also available for NodeJS. PHP has pooling support too, it keeps some connections open in the back where you cannot see but does not notify. In NodeJS, you have to deal with it yourself. There is helper modules to achieve this, I would certainly suggest you to have a look at this example It is not such a big deal.
I was wondering if there is a way to use mysql server through sockets.
What I want is connecting running queries and getting results by making socket connections and sending packets. Does anyone know how can I interact with mysql this way?
Regards
Almost every language has a MySQL client, so I'm not sure why you want to do this.
But, you would basically have to reimplement the client library. The protocol is by no means simple: http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol.
You could perhaps write basic functionality, but once you get into all the features and corners of the protocol, it would be a project tremendous in scope (with no purpose).
I've been doing some research of the best way to show an "users online" counter which is updated to the second trying to avoid continuos ajax polling.
Obviously WebSockets seems to be the best option. Since this is an intranet I will make it a requirement to use Chrome or Safari so there shouldn't be compatibility issues.
I've been reading some articles about WebSockets since I'm new to it and I think I pretty much understand how it works.
What I'm not so sure is how to implement it with PHP. Node.js seems the natural choice for this because of it's "always running" nature but that's not an option.
Why I'm most confused about is the fact that PHP runs and when it's done, it ends. If PHP ended, wouldn't the socket connection be lost? Or if the php re-runs it will look back the user by ip? (I don't see that likely)
Then I found this library
http://code.google.com/p/phpwebsocket/
but it seems to be a little old (it mentions only Chrome nightly is compatible with WebSockets)
In one point says "From the command line, run the server.php program to listen for socket connections." which means I need SSH, something many shared hosting plans don't have.
And my other doubt is this other line in the source of that library:
set_time_limit(0);
does that mean that the php file will run continuously? Is that allow in shared hosting? From what I know all hostings kill php after a timeout of 1 o2 minutes.
I have a mysql table with online users and I want to use PHP to broadcast via websocket the amount of logged in users to those online users. Can someone please help me or point me somewhere with better information how this could be achieved?
Thanks
Websockets would require lots of thing even on dedicated hosting, put aside shared hosting.
For your requirement server sent events (sse) is the correct choice, since only the server will be pushing data to the client.
SSE can simply call a server script, very much like ajax, but the client side will receive and be able to process data part by part as it comes in. Dom events would be generated whenever some data comes in.
But IE does not support SSE even in version 10. So for IE you have to use some fallback technique like "foreever iframe".
as far as hosting is concerned, ordinary shared hostings (and those which are not very cheap) would allow php scripts to run for long, as long as they are not seen as a problem.