I'm new in the WebRTC and Websockets world. I'm interested in making an 1 vs 1 web game.
The problematic is just : How to send simple variables (mainly numbers) from a client to the other client ?
I have a Node.js server with websockets (via socket.io).
So, for the clients, I have two solutions :
Using Websockets : The client 1 push the var to the server and the
server push the var to client 2. This solution allow me to easily adapt my application for many users in one game.
Using WebRTC : The offer and the answer are sended via the server with websockets. Then, the client 1 push the var to the client 2 via DataChannel (I don't need getUserData)
I prefer using WebRTC because it eases the work of the server, that allow him to manage more clients.
So I set up the two solutions to compare and, big surprise ! Websockets are highly faster than WebRTC !
My test is simple : just a cube rotating using Three.js, the first client make a little rotation at each frame (60 per second) and push the rotation result to the client 2. At the reception, the client 2 update the rotation and render.
With Websockets, the result is perfect but with WebRTC, the client 2 runs really slow, like 5 FPS.
Is that the problem is the way I'm doing it ? Is it normal ?
I'm working on localhost, on Firefox.
The problem is with WebRTC. The WebRTC DataChannel implementation on Chrome (probably the same goes for firefox) is limited to around 30 kbps. I don't know the reason why? Something about not flooding the internet. There is a hack to circumvent this limitation - manually changing the "B=" filed in the SDP before setting it.
However... WebRTC is p2p UNRELIABLE communication. This means that you have to take extra care to ensuring that no messages are lost and the two players observe the same events and environment. I would go with websockets just because they are so much easier, understood and supported. If the game goes viral I would consider WebRTC as a possible optimization.
However if you are doing this game just for fun then you will learn a lot of useful stuff if you choose WebRTC.
If you want to see an example how webrtc is used in real projects take a look at:
http://viblast.com/demo
NB! After the introduction of SCTP-based data channels at around the Chrome 31-32 time there is no bandwidth throttling any longer and there is a new mode of operation which allows for reliable data channels.
Related
I need to set up a (bidirectional) communication channel between a C# application and a Max for Live Patch (Max 6).
One can run JavaScript inside a Max patch (pretty lightweight) and I thought about using named pipes inside JS for sending data out to a C# server. However I have no clue how to set them up in the Max environment because things like ActiveXObject cannot be used.
Is this possible to achieve or do I have to write a Max Extension in C as a proxy?
(Or should I rather go with a network connection?)
Any hints welcome!
Regards,
Moritz
I admit that I don't have much experience with named pipes, but regardless I would recommend setting up a network connection.
Most Max users that need to communicate with other applications use the native UDP objects udpsend and udpreceive along with the OSC protocol developed at CNMAT. I prefer TCP / Json myself, and have been frustrated by the lack of native TCP support in Max. Depending upon the needs of your application, it could be very important to know when clients disconnect, to ensure that packets arrive in the proper order, etc--features UDP does not provide.
For this reason, I have started developing a native TCP client for Max using Unix sockets. Since you are using Windows, this won't work for you out of the box, but the basic building blocks could still be useful. If you want to add winsock support, that could be a great benefit to the Max community.
I am using Flask and I want to show the user how many visits that he has on his website in realtime.
Currently, I think a way is to, create an infinite loop which has some delay after every iteration and which makes an ajax request getting the current number of visits.
I have also heard about node.js however I think that running another process might make the computer that its running on slower (i'm assuming) ?
How can I achieve the realtime updates on my site? Is there a way to do this with Flask?
Thank you in advance!
Well, there are many possibilites:
1) Polling - this is exactly what you've described. Infinite loop which makes an AJAX request every now and then. Easy to implement, can be easily done with Flask however quite inefficient - eats lots of resources and scales horribly - making it a really bad choice (avoid it at all costs). You will either kill your machine with it or the notification period (polling interval) will have to be so big that it will be a horrible user experience.
2) Long polling - a technique where a client makes an AJAX request but the server responds to that request only when a notification is available. After receiving the notification the client immediately makes a new request. You will require a custom web server for this - I doubt it can be done with Flask. A lot better then polling (many real websites use it) but could've been more efficient. That's why we have now:
3) WebSockets - truely bidirectional communication. Each client maintains an open TCP connection with the server and can react to incoming data. But again: requires a custom server plus only the most modern browsers support it.
4) Other stuff like Flash or Silverlight or other HTTP tricks (chunked encoding): pretty much the same as no 3). Though more difficult to maintain.
So as you can see if you want something more elegant (and efficient) than polling it requires some serious preparation.
As for processes: you should not worry about that. It's not about how many processes you use but how heavy they are. 1 badly written process can easily kill your machine while 100 well written will work smoothly. So make sure it is written in such a way that it won't freeze your machine (and I assure you that it can be done up to some point defined by number of simultaneous users).
As for language: it doesn't matter whether this is Node.js or any other language (like Python). Pick the one you are feeling better with. However I am aware that there's a strong tendency to use Node.js for such projects and thus there might be more proper libraries out there in the internets. Or maybe not. Python has for example Twisted and/or Tornado specially for that (and probably much much more).
Websocket is an event-driven protocol, which means you can actually use it for truly real-time communication.
Kenneth Reitz wrote an extension named Flask-Sockets that is excellent for websockets:
Article: introducing-flask-sockets
Github: flask-sockets
In my opinion, the best option for achieving real time data streaming to a frontend UI is to use a messaging service like pubnub. They have libraries for any language you are going to want to be using. Basically, your user interfaces subscribe to a data channel. Things which create data then publish to that channel, and all subscribers receive the publish very quickly. It is also extremely simple to implement.
You can use PubNub and specifically PubNub presence meant especially for online presence detection. It provides key features like
Track online and offline status of users and devices in realtime
Occupancy to monitor user and machine presence in realtime
Join/Leave Notification for immediate updates of all client connections
Global Scale with synchronized servers across the PubNub Data Stream Network
PubNub Presence Tutorial provides code that can be downloaded to get presence up and running in a few minutes. Five Ways You Can Use PubNub Presence shows you the different ways you can use PubNub presence.
You can get started by signing up for PubNub and getting your API keys.
I've been playing with WebRTC and reading about the way it works, but I'm still quite ignorant of what's really going on under hood when it comes to peer connections. The way that the streams are routed, won't it choke if there's too many participants in a video conference without some sort of central server, if they all have to connect to one another?
Has anyone experimented with this? Anyone care to take a guess at the threshold for your average broadband connection?
They will definitely choke whatever it is that you are doing.
You will need a central server, but that is up to you - WebRTC only deals with the media transport and communication part - you need to take of the signalling of it all on your own.
To that end, you can add a media server to handle multipoint conferences and have it do the orchestration of the conference.
You can look at webrtc.io
http://multiwebrtc.nodejitsu.com/#0
but like #Tsahi says it chokes .. chocked for me after 4 participants and cpu spiked to 100% lots of delays as well. When you are not doing 1 on 1
I wanted to be allow users to play p2p in a multiplayer game that I'm developing, but to be able to do that, javascript needs to be able to create a socket server in the browser. Is that even possible? I don't know of any API that let clients connect to other clients in javascript. Is there any other way? Like using a hidden flash element?
I am asking for something that doesn't require a server at all. The packets need to travel from client to client directly
In short no, p2p in a browser is not possible.
The closest you can get is using NodeJS (for potentially p2p JS) or a centralised server (or several servers) and websockets (for sockets in a browser)
This question is old, but I can now give an answer: YES, there is finally a way to do p2p communication between browsers!
Thanks to the new standard WebRTC, modern browsers got support for Data Channels, something much more powerful than WebSockets.
Take a look here:
WebRTC Data Channels
Online Example: Banana Bread 3D is a First Person Shooter game compiled to JS+WebGL, using WebRTC data channels in multiplayer mode:
BananaBread 3D Multiplayer online fps game
Interesting question, but probably a duplicate:
What techniques are available to do P2P in the browser?
i know for sure this can not be done using only javascript(in every browser). According to another answer on Stackoverflow in above topic you might be able do this using rtmfp-api.
This project expose Rtmfp protocol (provided by Flash version 10) to
javascript application throught a hidden flash applet. The protocol
allow multiple clients to communicate directly. See the references for
more details about the protocol.
Looking quickly at the site you still need a rtmfpUrl-server in the middle, which i totally understand because the clients need to be be able to find each other(IPs). But I assume after that it will be p2p. Doing a quick search I also found open-source rtmfp-server(s).
I haven't tried this out myself, but I maybe this will help you achieve your goal.
Some other links:
https://stackoverflow.com/search?q=browser+p2p
https://stackoverflow.com/a/7933140/11926
https://stackoverflow.com/a/5211895/11926
https://stackoverflow.com/a/5023048/11926
While this is a shopping question, i'd look into APE
http://www.ape-project.org/
At the very least you could check out how they've structured it.
In order to implement such a game, your JavaScript client must communicate with the server. The server then runs the game logic, and sends the result back to the client.
JavaScript receives user input and sends it to the server
Server ensures that the input is valid (to prevent cheating) and updates the game with the new input
Server periodically sends the game state to JavaScript (either by long polling or by having JS request it at an interval).
Basically, never trust anything coming from JavaScript as it is extremely easy to modify. Everything should be done server-side.
Here's a solution with mobl (but I haven't tried it yet).
http://zef.me/3391/moving-the-server-to-the-browser
It is possible to go serverless with Flash. This is doable with Adobe Flash's Peer to Peer capabilities. I once wrote a peer to peer chat with it. The drawback is Actionscript is a dying language and may not be supported much in the future.
Here is the raw class.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetGroup.html
Here is resources if you don't want to write your own.
http://www.as3gamegears.com/category/multiplayer/
If you want a Server option that is light on the server side. Try this node.js extension.
http://socket.io/
I recommend using a java socket server of some sort. Electroserver used to be one of the leaders in the field, it had Unity support and was scalable to hundreds of thousands. Although I think they have fallen on hard times. The Electroserver site has not been accessible for sometime. I know there are others out there but Electroserver is the only one I have used.
I´m planning to create a WebGL-based, realtime strategy game, where players are able to play together. I´ll use Node.js to create the game server, and websockets for realtime connections.
I´ve broken my mind about what would be the best concept to synchronize the clients.
One possibility would be to send only the orders of the users (moving units, building buildings etc.) to the server, which sends them to all other clients. But here, I have the problem of the delay. I think that the games would get async this way.
Another possibility would be to calulate the game on the server. The clients still send the instructions to the server, but the server sends now all changed states of all units&buildings to the clients in a high interval. The problem is here the high amount of data and how fast this can be...
Do you have some other ideas or improvement proposals?
Thanks!
Basically you have to decide between speed vs security.
Letting the client do the job and the calculations is faster but the data is at risk because the client can manipulate the data.
On the other side, having the server do all the job is slower but the data is more secure.
You could opt for a dual approach, decide to let the client calculate only some data, synchronize and then check for its validity, and let the rest being executed on the server.
It also depends on how fast the game runs, the amount of data to calculate, the speed of the server and band/connections, etc...
You should prototype both methods and try some tests to emulate the client and servers load.
If the game is small I would opt for a more server-side work. On the other hand, for a much complex game probably sharing more work to the client is best. Anyway I think a tradeoff is always needed.
Here are a few links you may find useful
Multiplayer Game Programming Introduction
Real time strategy networking
Multiplayer Programming thread (old but still with many useful links)
Lag Compensation
Prevent Multiplayer Cheating
The first link has helped me a lot back in the days and imho is still one of the best resources avaiable on the subject.
Books
Multiplayer Game Programming
I would suggest to watch these resources regarding browser based game development concepts:
Multiplayer Gaming with HTML5: Are We Ready?
Realtime HTML5 Multiplayer Games with Node.js
HTML5 Games 0.3: Seeing the Future
Unfortunately I have no experiences in WebGL based online games, but usually it is a good approach to let the game logic be executed on the client side, and synchronize the results.
In this approach it is important to keep track of what game object is "owned" by what client. Clients only send updates (creation, update, deleteion) from their own objects and receive the updates of the other game objects from the other clients.
Additionally you can set up a messaging framework to deliver additional messages like "Player has entered/left" or something like that.
This concept has proven useful for a game I created, and I hope it is as useful to you.
You should have the game state and logic on the server, otherwise your game is wide open to cheating. The server is the ultimate authority the game state.
Not sure about WebGL, but to my understanding following approach will be good.
Initialize all objects (which are common across players) on server and run them
On client start, it will request all renderer (related to specific client) for the objects running on server.
client will render the objects on UI for all recieved renderer.
When client make any update on UI, changes will be notified to server, and server will update the object accordingly
When objects common between players are modified by one player, each player (client) will be notified to make UI changes.
This approach will be specific to common objects not UI / client specific objects.
For security reasons, all the logic should be on servers side, and all the data update is on server.
But the client is able to predict some logic and play animation first, which is called client prediction.
The server side is in charge of verify the client logic, if there is no cheating, all done.
If there is someone cheating, the server can tell the client to go back to right state.
If you are using node.js for server, there is an open source framework , pomelo .
And there is also a full source code demo and online demo for it: lordofpomelo