I want to develop a little rpg game on a web application. To explain quickly, each players have a character sheet and can use skills and attacks that will deal damage to other players.
There is generally 5 players at the same time, and there is a chat functionnality in addition.
I would originally use web socket to make communication between players and server for exchange: messages, damages, or other data that need to be share in other players.
But i see there is the WebRTC too who create a peer to peer communication and exclude the passage by the server. But if I have understand, peer-to-peer is better for only two user ?
I don't understand really what is the best solution in this case and why ?
Best regards.
WebSockets are strictly client-server, just like plain HTTP: every client communicates with the server, and all client-client communication must be mediated by the server. WebRTC, on the other hand, allows clients to communicate directly among themselves, without going through the server. This gives lower latency, and better privacy, since the data does not need to go through the server.
In a large group, however, every WebRTC peer will need to connect to all other peers: with n peers, the total number of connections n(n-1)/2. For example, in a group with just 10 participants, you will need to establish 45 connections. Given the vagaries of the Internet, the probability that none of these will fail is essentially zero, so your application will need to be able to deal with partial connectivity, which is difficult to implement and almost impossible to debug.
In practice, peer-to-peer WebRTC is a good solution for groups with three or four participants, but unworkable beyond that.
Note that WebRTC can also be used in a client-server topology, which gives lower latency than WebSockets without the complexity of peer-to-peer error handling. Doing that requires a server-side implementation of WebRTC (my favourite is Pion), and is probably more involved than what you are willing to deal with.
Related
The architecture I have is that clients receive events from a service through websockets. We are building another service which also needs to communicate it's events to the clients. We are faced with a design decision - whether to change existing service or just add another websocket connection from client to new service.
It is technically complex and expensive to change the other service as it's not maintained by us, but at the end of the day, if necessary, it is possbile. Adding another connection to new service would be cheap and no redesign would be needed, but it would imply that there would be two connections in parallel.
Other questions i've looked at often get answers from server perspective, where TCP connections are limited and thus it's important to reduce the amount of connections, but it's obviously not applicable here, since it's two separate services. What i'm asking is that how big of a difference it is from a client perspective that instead of a single websocket connection there would be multiple connections? My view on this has been that our goal should be to use the same connection as each connection reduces performance, but to be honest it's just an opinion and not a proven fact.
Since it's enterprise setting, backwards compatibility and performance is highly important, but at the same time, development cost is way higher if we'd choose to go with one connection instead of two. So.. is there a real difference or it's something I should not worry about?
From a client perspective, on any modern platform, the difference in cost of managing one vs two sockets in an application or browser should be negligible. It sounds to me like simplifying development and maintenance effort should dominate your decision.
I want to build a real time online multiplayer game. After researching WebSockets and WebRTC, I've come to the conclusion that WebRTC is exactly what I need if I was building a p2p game. However, WebRTC seems like its not meant for handling group conferencing. This is because if there are "n" users, there will be "n-1" streams of data. This is obviously not scalable. There are smart ways to circumvent this, like using https://github.com/jitsi/jitsi-videobridge and other solutions. But essentially it seems that WebRTC is meant for one-to-one communication. Most of the tutorials out there serve that purpose, not group conferencing.
Questions -
I've read that Google Hangouts and Facebook Messenger use WebRTC for their group video chats but how exactly have they solved this problem?
Are server based Websocket implementations like uws viable for real time communications? (due to added latency)
Is there any plan to address group conferencing from the WebRTC or is WebRTC just not meant for this use case.
Thanks in advance.
I am building a set of programs that consist of multiple clients and a single server.
The clients are frequently pushing small packets of data to the server, which will validate the information (returning an error if the data is invalid), and process the received information. The information may then incur the firing of events, which clients will be subscribed to, allowing for clients to be instantly (or as close as possible) notified (along with a small amount of data).
I have some ideas about how to do this, but I am trying to avoid creating a protocol of my own, mainly as I'm sure it would take forever and I would probably make a few errors. So I was wondering if there are any existing protocols that I could implement into my system that would provide such functionality.
The number of clients will initially be quite small, but will be growing over time to potentially include 1000's of clients (with their own subscriptions), and several front end servers (each one handling a subset of subscriptions) parsing the information back and forth with back end servers for improved capability.
So, if anyone knows of any existing protocols that implement these requirements and functionality, that would be fantastic.
EDIT
I am currently looking at the XMPP protocol, and the JXTA protocol suite (for reference, and implement with another language). Both seem quite good and provide the necessary connectivity, but I have not had the opportunity to test each of them out in my environment, or if they are even suitable for what I am attempting.
Additionally, some of the network clients will be outside of the local network and operating over WAN. Security is not so much of an issue, but I need to take into account the increase latency of this, and firewall rules (local to the connection that is hosting the application and ISP firewalls) that could be blocking certain ports or transport protocols (I have read some text that said that some ISPs where blocking UDP packets, but not sure of how wide this goes. I can do it at home, the office, mobile, friends houses, etc and have yet to experience it myself).
I'm sorry if the following is not exactly what you're after but I am slightly confused by your use of the word 'protocol'. I understand a protocol to be a 'communication specification' only, where the implementation is left entirely to you. If that is the case I always find the the following graphic usefull, link.
If on the other hand you are looking for a solution which allows you to easily implement the networking side of your application, helping save time, then checkout the following network libraries, which implement their own custom protocol:
NetworkComms.Net
Lidgren
ZeroMQ
Disclaimer: I'm a developer for NetworkComms.Net
I am about to make a turn-based game in the Monkey language (Cross-platform translator). The game will use the HTML 5 platform. This game will play online where players can match against each others (It can be a 2vs2 match). I recently reviewed a tons of solutions and i stopped on 2 of them. The good old XmlHttpRequest and the new one WebSocket which seem to be in a recommandation state from W3C which is rather good. There also another technology which i was interested which is PubNub, a push service. This service actually push messages to all clients connected and is really fast.. but this come at a cost later and is restricted in the number of messages you sent. By that i mean it cost you 15$ per month for 1000 connections and 1million message then +1$ for another 1 million and go on. There actually 3 actors, the client written in monkey (HTML5) the server written in C# because i know well the language and PubNub for broadcasting messages. The client will only send requests to the server and the server is relaying the messages to PubNub which in return send back to clients. I had two plan in head considering thoses facts :
The game is written in HTML 5 but i may port it to other languages (Android as an example). I can't do that if i use WebSockets because i would have to get additionnals librairies to handle this and i don't want to invest more time in it. So i will focus on HTML 5 for now but porting it is alway an option.
Its a turn-based game so yeah XmlHttpRequest seem to be suitable for this task but at which point ? If i have over 1000 connections sending requests will it be able to support it ? Each turn is an unique request but chat messages is also a request and private messages too, getting player data too (before you join any game) etc. An advantage over WebSockets is that Http Get are easy to make and is supported easily on many platforms so i could obviously go the Android route if i choose this.
I don't want to invest more time in others technologies than thoses stated here.
PubNub cost money in the end but it is very efficient for pushing messages so not using it might be risky and would force me to do the messages relaying code myself.
So here my 4 plans.
Going with WebSockets and use Alchemy as a WebSocketServer for C# which i tested and work wonderfully and still have the PubNub actor in the backend for relaying my messages.
Go with XmlHttpRequests and use a simple WebAPI for the request Gateway.
Go with both. Make the client independent on which technology to choose. Use XmlHttpRequest as a fallback and make the server support both connection. PubNub will still be the relaying actor here which should make the whole stuff communicating.
Go with WebSockets but without PubNub.
So which route do you recommand me to go and why ?
Thanks!
PubNub for Indie Games and Multiplayer Online Worlds
Networking is hard when you are building a simulated world for people to explore. These simulations are often considered. PubNub is the best solution for indie game developers for all the good reasons. Enable Networking in your Indie Game is simple with PubNub's two easy functions PUBNUB.publish({...}) and PUBNUB.subscribe({...}). Adding Networking in your apps allows you to implement multiplayer games and more! Implement real-time notifications between HTML5 browsers, phones, tablets and more. Everything can send and receive data from everywhere on Earth.
WebSockets or XMLHttpRequest or both?
PubNub makes this choice for you, automatically detecting the best connection type suited for your player's systems and capabilities. That means your Indie Game will function as expected on all platforms including Android, iPhone, Chrome / Firefox / IE and more. That makes it easy, so you don't need to worry about transports or delivery methods to the diverse number of platforms that exist. Your team only needs to focus on making a compelling and engaging online multiplayer game.
Online Indie Game - Server Logic
You need a way to securely collect player progress and track actions and consequences on your world. You may also need to track inventory and player state. There are two great services for this.
RoarEngine
First let me recommend http://www.roarengine.com/ RoarEngine an online hosted Game Engine which gives you a Scripting Engine to Unleash your creativity with limitless possibilities by writing your own custom logic. Events, challenges, timed mechanics, you name it. RoarEngine also offers Items & Gifts economy to Shape player interactions by creating items that affect player state, powered by a full featured shop, currency and gifting system that can be managed on the fly.
Parse
I highly recommend https://parse.com/ an online cloud hosted service which managers you user/player sessions. Parse is great when you need an online platform for more abstract and less tailored to gaming; which allows you to define models and objects in the way you choose. With Parse you don't need to focus on building infrastructure, you instead get to focus on building your game world state.
PubNub HTML5 MMO XKCD Game Multiplayer
We wanted to demonstrate the capabilities of HTML5 Indie Games used together with PubNub to enable expansive gameplay that joins players all across the world in real-time. This game uses HTML5 Canvas with multiple users flying around with a balloon figure. If you got stuck, you can click your balloon guy and turn into a ghost to seamlessly move through the landscape unhindered by mortal barriers like trees and hills. There was a problem however with the scaling of users on ordinary off-the-shelf gaming servers. The max concurrency could only be a few users at a time leaving many wonder where the MMO part of the MMO was. PubNub makes this automatic and at a lower cost compared to self-hosting options. Teams who are considering self-hosted options will consider the cost compared to maintaining and hosting a networking cluster for gameplay.
PLAY LIVE - http://www.pubnub.com/static/pubnub-xkcd/index.html
BLOG - http://blog.pubnub.com/xkcd-mmo-websocket-scaling-with-pubnub/
SOURCE CODE - https://github.com/pubnub/pubnub-xkcd
The links above show you a live HTML5 Canvas based game that is powered by PubNub multiplayer capabilities.
Take a look at http://realtime.co - Its a Realtime platform similar to PubNub and with more capabilities.
Just wondering: Would it be acceptable to start some simple Ajax instant messaging (web-based) for a large social network service (considering thousands of registered users)? I am new to this, so I'm just wondering. What if to check for a new message every two or three seconds?
Edited: Could a plain shared server handle so many requests every so often? And yes, I would roll my own program.
There're many web im client based on standard XMPP protocol. You could try iJab or JWChat.
It doesn't make sense to write your own, unless you have some unique requirements, but whether the server can handle this largely depends on the server language and webserver setup, as to how well it scales.
You will need to do some heavy load testing, to ensure that the high load that is expected will work, as your traffic will be very heavy. For example, if your social networking site is soccer related, then during the World Cup you may expect to see more traffic than Wed mornings.
If you asked the question with:
I want to use language X.
I want to use webserver Y.
I am using this framework for the
webservice.
I would like to accept voice
recordings and webcam recordings
over IM, as well as text.
How well will this scale on my one 1GHz server?
If you manage to make a peer-to-peer (P2P) browser-embedded chat, than even a shared hosting will do for dozens of thousands of simultaneous users :) :)