Hi Ale and everyone else who replied,<div><br></div><div>That's exactly the point, I don't think HTTP is necessary at all! There is the overhead of sending extraneous HTTP headers over the wire. All of those additional bits take additional CPU time and bandwidth (on a mobile device with limited CPU and even more limited bandwidth!). I see absolutely no need for sending HTTP headers and parsing them from the response for this, particularly because I am not building a web browser based application. I have access to C/C++/Objective-C (on iOS) and Java (on Android) and these are perfectly capable of working with TCP sockets. A friend of mine suggested that I just pass messages to the server as JSON using a prefixed header that specifies the length of the message. That would be it! Simple and compact. </div>

<div><br></div><div>I just wanted to validate the idea and see if others thing I'll run into too many edge cases uses TCP sockets via an RPC type server to build this server/client architecture out. I want to really make it reusable so all of my mobile products can use it. </div>

<div><br></div><div>Loving all the advice coming in! Thanks all.</div><div><br></div><div>Matthew. <br><br><div class="gmail_quote">On Tue, Jul 12, 2011 at 5:03 PM, Ale <span dir="ltr"><<a href="mailto:peralta.alejandro@gmail.com">peralta.alejandro@gmail.com</a>></span> wrote:<br>

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