Am wondering if there are any drawbacks of using Adobe Stratus. Since it is only P2P, when will there be a case where P2P can't be used? On the site it says something like when UDP packets are blocked. How often is that? Say a thousand people use the service, approximately what percentage would not be able to use it?
Also, is it possible to port a Stratus app to AFCS/LCCS without any modification?
Thank you for your time.
About half on average are not able to talk directly. Depending on service provider, organization if any, country, continent, weather, extraterrestrial presence etc :-)
with a pretty global audience, i had about 20% failing the initial test with cc.rtmfp.net . then a number of those who passed couldn't make direct connections to some users, although they could with others.
i wouldn't use stratus by itself for anything where reliability matters. use fms until red5 adds support for rtmfp
I have been looking at this for a client who is developing a peer to peer video conferencing app.
In his experience about 10%+ of people out of a small group surveyed had UDP blocked, and therefore were unable to use Adobe Stratus to make connections and LTMFP
Related
I am building a multiplayer game where players are simultaneously asked a question and they have to pick an answer. They have a few seconds to answer and they are asked the next question when the time is out or everyone has answered.
I am planning on using Java (or nodeJS if I feel like learning a new framework) on the server side and JS (jQuery and jQuery Mobile) on the client side. I might build native apps later too so I want to keep the option opened.
My question is: what server communication protocol would you suggest?
I was thinking of regular TCP (HTTP with Ajax) calls since latency is not really the issue but I am ready to review this choice if you suggest otherwise.
Thanks a lot for your help
When using UDP the burden to implement retry and congestion control will fall on you. Therefore, I recommend you stick with the reliable and easy TCP until there is a specific reason to switch. If latency turns out not to be acceptable, which I doubt in your case, you can switch to UDP.
Another thing to remember, if you are creating the game on mobile device and you don't want to lose the players connected over 3G, you will need to make sure you are using standard ports to connect to the server side, otherwise operators will disconnect you.
HTTP Streaming and WebSockets over TCP/IP is the best way to go. Lightstreamer, which leverages HTTP and WebSockets, uses TCP but tries to overcome some of its limits with some smart algorithms for latency reduction (which seems to be crucial for the game you described) and bandwidth optimization. Thus, it can be used with great benefits for any multiplayer games of any complexity (including MMORPGs, for example). At a first glance it seems it can fulfill your requirements, and it could be a good solution if you are also planning to develop native apps in a second step.
Lightstreamer is based on a publish/subscribe model, in which every item is defined by a set of fields whose values can change over time (in order of milliseconds). These could include "general items", subscribed by any users (e.g the game countdown; who is the first responder) and delivered in real-time. This way, the data delivery mechanism underlying your game logic seems quite easy to implement with Lightstreamer.
Have a look at this recent article (Optimizing Multiplayer 3D Game Synchronization Over the Web). You can walk through an online demo of a simple multiplayer 3D world in which Lightstreamer has been integrated for real-time synchronization.
The demo allows you to tweak each parameter of the scenario and simulate any flavor of data delivery, while checking the actual bandwidth consumption. Of course, full source code is available for free on GitHub. You could give it a try. Let me know if you need some help :)
[full disclosure: I work for Lightstreamer]
Does anyone have experiance in a lot of these?
I'm not so intrested in the pdf creation part of LCDS.
Just for flex messaging which would give me the best performance? As far as I know LCDS and WebOrb both do real time streaming is that correct?
Basically the question is which gives quickest response and which will allow for most client connected to a single servlet container.
Thanks
Edit 1
This may be clearer what I want. I'm looking to server at least 5000 clients with sub second response times with push messages, I'm trying to figure out which is the most scalable option, I've been quoted several million push messages a day. Obviously we can throw more servers at the problem I'm not convinced thats the most maintainable option.
Its not media streaming I'm looking for, but more event updates. It must work without sticky sessions.
LiveCycleDS & WebOrb are the only ones providing messaging using sockets through RTMP protocol. Note that in this case the clients are not connected to a servlet container, but to a dedicated server included in the product distribution (bypassing the servlet mechanism).
There are more messaging servers on the market, Lightstreamer is one of them. Or Flash media server.
There are many more things to be taken into consideration when choosing a solution however (price, integration with various architectures (like DMZ) and frameworks, paid support, documentation, your relation with the sales representative etc).
Stratus is currently in beta !
So, if I create a simple app with stratus tecnology and I get millions of users, then how can I scale the application ?
How chatroulette have resolved the scaling issue ?
Stratus itself is [probably] a redundant distributed system of Adobe-owned servers accepting connections so rapidly that it is not an issue at all. On top of that, remember that Stratus simply distributes peer identifiers, and all other communication that is any bandwidth-hungry is peer-to-peer, which obviously does not suffer from scaling problems at all.
chatroulette use an array of Red5 servers that stream video in case peers cannot communicate directly (behind firewall/NAT etc), and they HAVE used a PHP/MySQL database backend for peer discovery (Stratus does not discover peers, it simply shares them on demand). I say "HAVE" because that's what it was at a very early point in time, they would be wise to not do PHP/MySQL now, because that would be a suicide with their amount of traffic.
UPDATE
It seems I was talking out of my a$$ when mentioning chatroulette using Red5. I have no evidence whatsoever of the fact, and may have remembered something wrong or confused it with some other service. I do have evidence it used FMS 3.5.2 as of the time of writing.
I'm making a network game (1v1) where in-game its p2p - no need for a game server.
However, for players to be able to "find each other", without the need to coordinate in another medium and enter IP addresses (similar to the modem days of network games), I need to have a coordination/matching server.
I can't use regular web hosting because:
The clients will communicate in UDP.
Therefore I'll need to do UDP Hole Punching to be able to go through the NAT
That would require the server to talk in UDP and know the client's IP and port
afaik with regular web hosting (php/etc) I can only get the client's IP address and can only communicate in TCP (HTTP).
Options I am currently considering:
Use a hosting solution where my program can accept UDP connection. (any recommendations?)
UDPonNAT seems to do this but uses GTalk and requires each client to have a GTalk account for this (which probably makes it an unsuitable solution)
Any ideas? Thanks :)
First, let me say that this is well out of my realm of expertise, but I found myself very interested, so I've been doing some searching and reading.
It seems that the most commonly prescribed solution for UDP NAT traversal is to use a STUN server. I did some quick searches to see if there are any companies that will just straight-up provide you with a STUN hosting solution, but if there even were any, they were buried in piles of ads for simple web hosting.
Fortunately, it seems there are several STUN servers that are already up and running and free for public use. There is a list of public STUN servers at voip-info.org.
In addition, there is plenty more information to be had if you explore SO questions tagged "nat".
I don't see any other choice than to have a dedicated server running your code. The other solutions you propose are, shall we say, less than optimal.
If you start small, virtual hosting will be fine. Costs are pretty minimal.
Rather than a full-blown dedicated server, you could just get a cheap shared hosting service and have the application interface with a PHP page, which in turn interfaces with a MySQL database backend.
For example, Lunarpages has a $3/month starter package that includes 5gb of space and 50gb of bandwidth. For something this simple, that's all you should need.
Then you just have your application poll the web page for the list of games, and submit a POST request in order to add their own game to the list.
Of course, this method requires learning PHP and MySQL if you don't already know them. And if you do it right, you can have the PHP page enter a sort of infinite loop to keep the connection open and just feed updates to the client, rather than polling the page every few seconds and wasting a lot of bandwidth. That's way outside the scope of this answer though.
Oh, and if you're looking for something absolutely free, search for a free PHP host. Those exist too! Even with an ad-supported host, your app could just grab the page and ignore the ads when you parse the list of games. I know that T35 used to be one of my favorites because their free plan doesn't track space or bandwidth (it limits the per-file size, to eliminate their service being used as a media share, but it shouldn't be a problem for PHP files). But of course, I think in the long run you'll be better off going with a paid host.
Edit: T35 also says "Free hosting allows 1 domain to be hosted, while paid offers unlimited domain hosting." So you can even just pay for a domain name and link it to them! I think in the short term, that's your best (cheapest) bet. Of course, this is all assuming you either know or are willing to learn PHP in order to make this happen. :)
There's nothing that every net connection will support. STUN is probably good, UPnP can work for this.
However, it's rumored that most firewalls can be enticed to pass almost anything through UDP port 53 (DNS). You might have to argue with the OS about your access to that port though.
Also, check out SIP, it's another protocol designed for this sort of thing. With the popularity of VOIP, there may be decent built-in support for this in more firewalls.
If you're really committed to UDP, you might also consider tunneling it over HTTP.
how about you break the problem into two parts - make a game matcher client (that is distinct from the game), which can communicate via http to your cheap/shared webhost. All gamers who wants to use the game matching function use this. THe game matcher client then launches the actual game with the correct parameters (IP, etc etc) after obtaining the info from your server.
The game will then use the standard way to UDP punch thru NAT, etc etc, as per your network code. The game dont actually need to know anything about the matcher client or matcher server - in the true sense of p2p (like torrents, once you can obtain your peer's IPs, you can even disconnect from the tracker).
That way, your problems become smaller.
An intermediate solution between hosting your own dedicated server and a strictly P2P networking environment is the gnutella model. In that model, there are superpeers that act like local servers, having known IP addresses and being connected to (and thus having knowledge of) more clients than a typical peer. This still requires you to run at least one superpeer yourself, but it gives you the option to let other people run their own superpeers.
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck