[erlang-questions] Is Erlang a good tool for this particular project?

[Miguel Morales]

I agree with the above poster, sounds like something like XMPP would
be good for.  There is a smack library for Android that I've heard
good things about.  When I was starting, because there was nothing
specific to mobile devices I ended up using RabbitMQ and its Java
bindings to build a realtime service that users could push/subscribe
to.

The way I do it, is on the server side I have some queue setup and a
bunch of worker processes running.
When the server gets a new message from the clients, one of the
workers processes it and updates the client information.  If the
workers are overloaded, the message is left in the queue until it can
be processed.

Polling on a device will shorten the battery life.  From some tests
I've ran (and I suspect is how google implements its C2DM service) it
appears that having a socket open doesn't activate the radio, it's
only activated until data is ready to be sent or read.

You can also implement RPC with a MQ server.  Although, it's not
strictly bi-directional.


On Tue, Jul 12, 2011 at 1:25 PM, Matthew Hillsborough
<matthew.hillsborough@REDACTED> wrote:
> Greetings Erlang community,
> Let me further elaborate on my question that's in the subject of this
> message. I tried to reach out with this question on StackOverflow, however I
> did not have much luck there. Perhaps the community here can provide some
> feedback here for me to let me know if I'm on the right track or if Erlang
> is not the right tool for what I'm trying to accomplish.
>
> I'm building native mobile applications in both iOS and Android. These apps
> require "realtime" updates from and to the server, same as many (but not
> all) network-based application does (Facebook, social games like Words with
> Friends, Finance applications, etc). The communication here is
> bi-directional, in the sense that the server might have updates for the
> mobile clients and the clients will be pushing data down to the server
> whenever necessary.
>
> I think using HTTP long polling for this is over kill in the sense that long
> polling can be detrimental to battery life, especially with a lot of TCP
> setup/teardown for every HTTP connection the device needs to send out
> through the wire. It might make sense to have the mobile applications use
> persistent TCP sockets to establish a connection to the server, and send RPC
> style commands to the server for all web service communication. This
> ofcourse, would require a server to handle the long-lived TCP connection and
> be able to speak to a web service once it makes sense of the data passed
> down the TCP pipe. I'm thinking of passing data in plain text using JSON or
> XML and then using some kind of Erlang interface to HTTP to call a web
> service to handle all the REST type communication. The responses would then
> go back to the "RPC" Erlang instance, which would send the updates to the
> appropriate client(s).
>
> Perhaps an Erlang based RPC server would do well for a network based
> application like this. It would allow for the mobile apps to send and
> receive data from the server all over one connection without multiple
> setup/tear down that individual HTTP requests would do. Since no web browser
> is involved, we do not need to deal with the nuances of HTTP long-polling at
> the mobile client level. I also haven't seen great long polling/keep-alive
> support on the client-side in iOS, but that's irrelevant for the community
> here.
>
> A lot of these "COMET" and long-polling/streaming servers are built with
> HTTP in mind. I'm thinking just using a plain-text protocol over TCP is
> better catered for the type of app I'm building, will make the client more
> responsive, allow for receiving of updates from the server without
> constantly polling the server, etc.
>
> I also looked into HTTP pipelining, but it doesn't look to be worth the
> trouble when it comes to implementing it on the clients. Also, I'm not sure
> if it would allow for bi-directional communication in the client<->server
> communication channel.
>
> Am I completely out of line in thinking that building a custom solution in
> Erlang is a good idea here? To my understanding, Erlang excels at servers
> like this, and if I run the server on tcp/80, I should be able to avoid most
> firewall/port issues. The client would need work to deal with timeouts, re
> connections, acknowledging receipt of asynchronous requests, but that's not
> Erlang's problem.
>
> Has anyone built something similar before? Should I just stick to a web
> server and deal with "COMET" type technologies? (WebSockets, long-polling,
> client-side polling).
>
> Was hoping someone could solidify that I'm not entirely insane for wanting a
> better solution than HTTP would serve in this case, at least at the client
> level. I'll still be using HTTP/REST extensively, the Erlang server would
> just handle the persistent connections and messaging to the Web Service
> (which would probably be something like Django or Rails).
>
> Sorry for the long post; I am just excited to get into the heads of people
> who are smarter than I.
>
> Happy hacking!
>
> Matthew
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>



-- 
~ Jeremiah:9:23-24
Android 2D MMORPG: http://solrpg.com/, http://www.youtube.com/user/revoltingx