Hi Joe,<div><br></div><div>Thanks for posting links to this. Surprised Joe A. did not mention it in his post, it has him listed as an author. :)</div><div><br></div><div>Just from a quick glimpse, this appears to be using MochiWeb, which is completely HTTP based. I am not entirely sure if that's the route I am looking to go, unless I am overlooking something here. With that said, there are probably parts of this code I can pick out and re-use in a pure TCP socket implementation (if this is indeed purely HTTP, which I suspect it might be).</div>
<div><br></div><div>Would love to hear I am wrong though so I do not need to reinvent the wheel.</div><div><br></div><div>Thank you and happy hacking -</div><div><br></div><div>Matthew<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 9:43 AM, Joseph Norton <span dir="ltr"><<a href="mailto:norton@alum.mit.edu">norton@alum.mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>Matt -</div><div><br></div><div>There is already a client and server implementation similar to your idea that uses JSON as the wire format over TCP/IP. See the section "JSF" for a brief description:</div>
<div><br></div><div><a href="http://norton.github.com/ubf/ubf-user-guide.en.html#_tcp_ip" target="_blank">http://norton.github.com/ubf/ubf-user-guide.en.html#_tcp_ip</a></div><div><br></div><div>Download and building instructions are here:</div>
<div><br></div><div><a href="https://github.com/norton/ubf-jsonrpc" target="_blank">https://github.com/norton/ubf-jsonrpc</a></div><div><br></div><div>Hope you find it helpful.</div><div><br></div><div>- Joe N.</div><div>
<div></div><div class="h5"><div><br></div><div><br></div><div><div>On Jul 13, 2011, at 9:42 PM, Matthew Hillsborough wrote:</div><br><blockquote type="cite">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" target="_blank">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" target="_blank">matthew.hillsborough@gmail.com</a>>:<br>
<div><div></div><div>> 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" target="_blank">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>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">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>
</blockquote></div><br></div></div><font color="#888888"><div>
<div>Joseph Norton</div><div><a href="mailto:norton@alum.mit.edu" target="_blank">norton@alum.mit.edu</a></div><div><br></div><br>
</div>
<br></font></div></blockquote></div><br></div>