So this is a tricky one.
I wish to write a web application which records a word said by the user, and then sends the samples to the server side for processing.
The algorithm I have in mind is as follows:
start a recording session once the user has clicked on a button
wait for the user to have said a single word (assuming he know he's supposed to say a single word)
stop the recording once he said it
send the samples to the server, say using HTTP
process the signal on the server side
send some response back to the user.
There are several solution for Voice Activity Detection in Java,C#, and other high level languages I presume.
However, I wish this part would to be done on the Client side (otherwise, I'll have to send too much data from the client to the server which is highly inefficient) I.E in javascript and HTML5.
I'm not an experienced web developer, so my questions are:
Is this feasible? Is there a library for that (I haven't found any)?
What would be the best approach in approaching the problem?
Related
I am writing a PHP backend, JS/Jquery front end application that will allow users to "communicate" in near real time. That is the hope at least, my question is what is my best course of action? Am I best to use WebSockets to send data between the server and client or would use AJAX and some sort of timer (x amount of seconds) be better. My worry with the AJAX way is that it may be taxing on the server to have 10+ clients all asking for data every 15-30 seconds. I need it to be near real-time and so 5 minutes is not really realistic.
An example of what I am trying to do would be if I had 5 users all on a page and user 1 updates their status, I would want users 2,3,4, and 5 to see the update as fast as possible without having to refresh.
I am mixed on what I think is best and I don't want to start doing it one way and find out it is insecure or terrible after getting halfway done. What is my best route with an application like this?
Here's a list of popular possible solutions:
Short polling (what you're referring to in AJAX
Long Polling (AJAX too, but not too many requests)
Websockets
WebRTC
So, for short polling as you've said it consumes lots of resources so let's remove that from the list.
as for long polling, its idea is that a request is send to server and the server doesn't respond unless a new event has happened (keeps the request) but its rarely used in modern development. so If you're going to work with other developers its kind of bad decision.
for WebRTC, browser compatibility is not that great and still a draft in W3C.
Thus, you're left out with WebSockets, and yes they consume ram but not CPU. ram is much cheaper (and it doesn't consume that much too).
As for security they can be considered equal (except for WebRTC which is better because it is actually P2P Communication)
Side note: don't overthink it :)
Here's some resources that can help you:
https://webrtc.org/
https://github.com/walkor/phpsocket.io //Socket library for PHP similar to Socket.io
https://socket.io
What are the realtime communication protocols available for the web? List of the protocols
https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9 great article for polling, websockets & covers SSE too
there is one way to make the RTC, RealTime App, Just Use the Socket.io "WebSocket " for signaling and before that take a full view of these webPages:
https://bloggeek.me/
https://www.html5rocks.com/en/tutorials/webrtc
https://w3c.github.io/webrtc-pc/#rtcsignalingstate-enum
https://www.w3.org/TR/mediacapture-streams/#legacy-interface-extensions
and i start to development this technology with this book enter link description here it will open your view of RTC usage and All Details.
My question is more related to validations of the movements in the game, the game is Checkers. I'm developing a Checkers game, in html, css, js, and nodeJS, the game will be multiplayer.
So my question is about the validation, what would be the best approach.
Right now all the validations (valid movement, etc) are done client side (of course must be server side).
My question is, what would be the best approach:
Having client side validation, if the validation is OK then send the validation to the server and validate it there if all is ok change turn for the next player, if not the server rejects the movement and the player have to do a valid movement.
No client side validation, just basics, all validation are done server-side.
Scenario 1: I think it's the best, because we don't rely that heavily on the server, if the movement client-side is wrong then it won't even send it to the server and if a player with bad intentions (modifying code) try to do bad movements there is the server with side validation.
Scenario 2: We rely more heavily on the server, it will consume more resources and will be slower for all online players overall, but it will be a little bit "faster" on the client side because there aren't as much validations as in scenario 1.
I think that Scenario 1 is the best approach because:
More security, client and server validations
Less lag for other player because only validated movements from the client will be validated in the server
Less Resources = Less infrastructure, so cheaper overall.
What's your opinion, or do you have a better approach?
Thanks all for reading.
This question is maybe a bit too open-ended and opinion-based for SO, but here goes:
Personally, I think having clients behave as "watchers" for the game server is ideal. The game server should be authoritative and do all the logic to ensure consistency.
I'm working on a networked JS game + engine right now and handle this as follows:
The server broadcasts 2 game states with timestamps to all clients. Each client then interpolates between state n and n+1. In that time, any user input is sent back to the server, which is then incorporated into states n+1 and n+2 which are sent on the next broadcast. When the clients reach n+1 in the interpolation, n+1 is corrected with the new pair of n+1 and n+2.
This means clients can experience maximum of 1 tick's worth of lag if an event was fired at the beginning of an interpolation and not broadcast to the other clients until the next state broadcast. This can be about 200 ms before it gets noticeable, but that's pretty tolerable in my experience.
I came to this method thanks largely to this incredibly useful set of articles by Gabriel Gambetta:
I. Client-Server Game Architecture
II. Client-Side Prediction & Server Reconciliation
III. Entity Interpolation
IV. Lag Compensation
Obviously I can't include all of the articles, but the gist of what I wrote above is in this image from the first article:
I would say senario 1 is better.
You need to use both types of validations. As a user clicks, show movement on the client side by javascript validation, and in the background send movement code to the server for validation so that player sitting on another can see it. Anyways you will have to send data to the server so that other player can see the movement of the player.
Add client-side validation also to prevent unnecessary request to the server and it will also increase waiting time for the player.
I usually prefer validation on server side for the following reasons:
Client is not loaded with validation burden.
In case validation fails, the back-end is aware thus, failures are logged centrally and you may decide on certain actions upon several failure cases. (post a message? send an email? see failures trending?)
Easier code debugging.
The client code is not trustworthy security wise.
Related to the game, you will have to send updates anyway so, your code will be more manageable if it is all server side and you may optimise various aspects of it.
tip: use socket.io, it is very easy to grasp, very reliable, supports server push messages
I'm writing a chat application from scratch, and I'm trying to figure out the best way to retrieve messages from the server in real time. I've done a fair amount of research, and have come up with this: I could use web sockets, and I've seen it done before successfully. I could use long polling, but I'm wondering if that places greater stress on the server, or maybe is just not right for a chat application. I could poll the server every second, but that just seems like a waste of bandwidth. Suggestions? Thank you!
The websocket protocol is ideal for something like a chat application for several reasons.
As you've already identified, continous polling of the server is quite a waste of resources.
Using traditional HTTP requires the use of bulky headers which waste valuable bandwidth. Websockets allow for lean messaging.
Most importantly for your application, unlike HTTP, websockets are bi-directional, meaning that your server can independently send messages to your chat client. With HTTP, all communication must be initiated by the client, and you are restricted to a request-response type of communication. With websockets, if your client receives a message from another user on your chat service, the server can immediately and independently relay that information to the intended recipient.
So to answer your question. You should definitely go with web sockets. Since you lack traditional headers, you will have to do a bit of work when it comes to formatting the messages sent over the connection, but the efficiency is well worth the minimal effort it takes to set up your messaging model.
What? Do you need to and from a database on a dedicated server?
I would recommend Ajax with JavaScript or jQuery but i like to do my own coding so JavaScript.
If your showing data back and forth match i would probably use MySQL.
For example to query up the last known query if matches current then would not be updated.
If doesn't match loop up from last to rent match would be DESC if in Order by type. Anyways...
Hope this helps you decide on what you should use.
Although this is what is common on games, blogs, forums, chats with MySQL/SQL.
I'm creating a multiplayer HTML5 P2P game; and I would like to use WebRTC to communicate without the server.
I know that there is no way to prevent from JS modification from the browser, but anyway, I would like to know : is WebRTC secure enough ?
Can a user can modify on-the-fly what the packet contains ? Or does DTLS+SRTP prevent from that ? If I communicate with another player, how can the user B be sure that the packet has not been modified since it has been written ?
I would say that it is, because TLS involves that there is Diffie-Hellman key-exchange; and all the communications should be AES + signed with SHA. So I'm guessing that is secured.
Am I wrong ?
Can a user can modify on-the-fly what the packet contains?
No.
Or does DTLS+SRTP prevent from that? If I communicate with another player,
how can the user B be sure that the packet has not been modified since
it has been written?
Yes.
However, if you don't trust A you cannot trust what he did write.
Nothing on the client is cheat-proof. Keep in mind that the browser is just a means for users to send messages to your server (or to other users in your case). A determined malicious individual could fabricate the messages himself without a browser.
Encryption exists to prevent a third party from reading/altering messages sent between two individuals. It can in no way prevent one of the two individuals from sending other messages than you intended and correctly signing them.
What you can do is validate on each client that the messages received from the other "make sense", that they fit in the context they are received in. A trivial example would be a chess game where a player sends a message that would teleport his piece in a place where it cannot legally move. In this case if both players know the state of the game (necessary i think), then the second player can and should determine that the move was invalid and somehow respond to that (either terminate the game or attempt to recover from the invalid state).
I have seen many webbrowser based games with players playing simultaneously.
Usually after waiting some time you can join a room where everyone is playing or you can play against one other player.
All those games use Flash.
How they achieve that?
It would be very complex to accomplice without Flash?
There are any toolkit (rails, etc) or plugin that provides this functionality?
Or it is just a matter of storing sessions and mixing them ?
Just a quick edit:
I am not interested in Flash or Silverlight solutions
There are a couple options for a JavaScript-only solution. They all involve AJAX of one form or another. (See my answer on AJAX and Client-Server Architecture with JavaScript for a larger breakdown.)
You have a choice between AJAX Polling, Long Polling, COMET, or the upcoming Web Sockets. The first step is to understand AJAX. Once you are comfortable with it, you can setup a polling system (with setInterval) to poll the server for new data every n miliseconds.
It's possible to do it without flash if you're comfortable with ajax and your game doesn't require rapid interactions between users. But in either case, I believe you have to poll the server. You might also want to read about comet http://en.wikipedia.org/wiki/Comet_(programming)).
Can you clarify what kind of game you would like to make? Turn based or real-time?
Since you're not interested in flash or silverlight solutions (which can use sockets and thus scale well with thousands of users) you can use javascript and use ajax to send and receive data.
Essentially you can use ajax like a socket by sending out input then letting the script "long poll" the server by having the server delay responding to it until it has data to send. The only problem is that you can only keep a connection open for so long before it times out (~30 seconds). This isn't usually a problem though since you're passing data back and forth frequently.
I'd research fastCGI (or so I believe it can work like this) and have a game server daemon respond to the requests directly. That way it can open a single database connection and process all of the clients quickly. While this isn't necessary it would probably scale really well if implemented correctly.
At the moment I've been making a proof of concept that's kind of naive. (Less naive than using the database as state and just using PHP scripts to update and receive the database's state. I should note though that for a only a few users and your own database this works rather well. I had 20 clients walking around at 100 ms updates. Sure it doesn't scale well and kills the database with 10 connections per client per second but it "works"). Basically the idea is that I have javascript generate packets and sends them to a PHP script. That PHP script opens a unix domain socket and forwards the data to a C++ daemon. Haven't benchmarked it though, so it's hard to tell how well it'll scale.
If you feel comfortable though I really do recommend learning flash and socket networking. Using Epoll on linux or IOCP on windows you can host hundreds of clients. I've done tests of 100 clients on a C# socket server in the past and it took less than 5% CPU handling constant streams of small packets.
Depends what technology you want to use. Flash can be used to create a game like that, so can Silverlight. They both use javascript to send mouse movements and other user input asynchronously to the server so that the game state can be updated on the server.
An article of flash game development:
http://www.brighthub.com/internet/web-development/articles/11010.aspx
Silverlight:
http://www.brighthub.com/internet/web-development/articles/14494.aspx
Java Applets are able to communicate with JavaScript (e.g. you want your UI to be HTML&CSS). So in theory you could implement your network code in a signed Java Applet. In this case you would not be limited to the plain client-server model.