Thanks for the inputs. I might just try firebase instead of trying to build 
my own solution. Either that or use XMPP which I have working right now 
using a resource for each client connection.

I did start down the NodeJS path as well just like Kris is doing except I 
used socket.io with NodeJS and was using python for the client. It worked, 
but my concern was scalability and what happens when the NodeJS server 
can't handle all the websockets. When you add more nodejs instances and 
load balance them, it makes things a lot more complicated.

So I prefer to try and make XMPP work because that's what the GAE channel 
API uses in the background anyway, but firebase does look tempting.

On Tuesday, March 19, 2013 6:30:21 PM UTC-4, Kristopher Giesing wrote:
>
> I ended up writing my own solution, which is essentially a replacement for 
> the channel APIs.
>
> The solution involves a node.js service that multiplexes to the clients. 
>  I used websocket-node (https://github.com/Worlize/WebSocket-Node) on the 
> node.js end, and SocketRocket (https://github.com/square/SocketRocket) on 
> the iOS end. I had tried several other persistent-connection solutions for 
> node, but none of them gave me the combination of flexibility and 
> reliability that I needed.
>
> I've been considering posting the code somewhere since it's pretty simple. 
>  The advantage to it is that it's free (other than hosting costs, which run 
> me $200/year, but I was already paying that).  The disadvantage is that, 
> well, it's custom, so it's not as well tested as some other solutions might 
> be.
>
> - Kris
>
> On Tuesday, March 19, 2013 2:06:10 PM UTC-7, Vinny P wrote:
>>
>> Hi Arthur,
>>
>> I'm not the original poster, but I deployed a simple communications app 
>> recently and I used a new company called Firebase. Firebase is still in 
>> beta, but it basically handles the entire communications backend for you, 
>> and all you need is some javascript on your side. Here's a quick tutorial 
>> on it: https://www.firebase.com/tutorial/#gettingstarted
>>
>> (Not affiliated with them, just a happy customer.)
>>
>> -Vinny P
>>
>>
>>
>>
>> On Monday, March 18, 2013 2:33:57 PM UTC-5, Arthur Wiebe wrote:
>>>
>>> Hey Christoph, may I ask what you ended up doing?
>>>
>>> I thought about registering one gtalk account and use it within the game 
>>>> client (register each client with a unique ressource, or maybe with a 
>>>> ressource per game). So basically the GAE app would send messages to 
>>>> my_customapp [at] gmail [dot] com/<uniqueuserid>, but i'm not sure if this 
>>>> would be allowed by google. Maybe someone here has some information about 
>>>> that?
>>>
>>>
>>> I'm considering doing that as well. Unless there is a better way.
>>>
>>> On Sunday, 15 January 2012 16:45:48 UTC-5, Christoph Grossegger wrote:
>>>>
>>>> thank you for mentioning and sharing your experiences with pubnub, 
>>>> althought it seams a bit expensive for my purpose (at least the pay as you 
>>>> go system, haven't calculated the prepaid options yet). It looks 
>>>> interesting for applications with somehow "moderate" update rates / 
>>>> pushes, 
>>>> since you get the whole package from client to server apis, but in my case 
>>>> here, it looks really expensive. 
>>>>
>>>> If i understand the pricing model right, i would pay 5 credits per 
>>>> message on a broadcast to 4 players (currently the maximum player size per 
>>>> game), 1 to the system and 1 for each player. One credit costs "only" 
>>>> $0.0001 (which makes $0.0005 per broadcast), which doesn't look much, but 
>>>> throughout a game, there are a few of those. Let's say each player 
>>>> performs 
>>>> every 4 seconds an action that requires a broadcast, results in 1 
>>>> broadcast 
>>>> per second per hosted game. That would cost a lot of money. Guess that an 
>>>> ec2 instance would cost way less and running the game logic directly their 
>>>> would also reduce the latency and the load of other instances. 
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to