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

Joe Armstrong erlang@REDACTED
Wed Jul 13 09:16:25 CEST 2011


On Tue, Jul 12, 2011 at 11:03 PM, Ale <peralta.alejandro@REDACTED> wrote:
> Hi,
>
> Just a thought here... Erlang is great for scalability and handling
> multiple connections, and well I'm sure a lot of people can give you a
> better description fo this, but it occurred to me if you considered
> other protocols instead of HTTP?

YES - YES - YES

Listen carefully - radio bandwidth is *extremely* limited - if you are
making an andriod
application you should weigh each byte on golden scales.

At the moment the demand curve for radio bandwidth is far steeper than
the supply curve.
We are running out of bandwidth fast - which is why I can't read
aftonbladet on the underground
any more - the first page takes longer than the journey time. If I was
the only person
with a smart phone that would be fine - but I'm not. Even the
low-bandwidth text applications
crawl along when in on the underground. All of this (looking at
aftonbladet etc) when I'm out of
the congested zones.

We (Ericsson) are churning out radio base stations as fast as we can
manufacture them, the
demand is insatiable.

As people move to smart phones they use c. 4 x the bandwidth they used
prior to smartphones.

Within one 3G cell there is a total of c. 2.4 MBits/second that must
be shared by *all* users in the cell.
bandwidth is not unlimited it is a finite and limited resource. 4G
makes life better with better protocols and
encoding methods.

Bandwidth (ie the 2.4 MBits) is a limited *shared* resource - this not
fibre - this is a limitation
reflecting the laws of physics and has nothing to do with engineering.

Since bandwidth is a limited resource people will get really pissed
off when they get bad response times.
As the 3G network get congested they drop back to GRPS/edge etc and do
packet switching which places even
more load on the networks.

So the rule for mobile apps is

Cache as much as possible - send and receive as little as possible and
weigh each sent and received
bytes on golden scales.

Bandwidth and bytes sent/received costs money. Most accounts cap data sent/month
so even though you have unlimited access they may well cut you back to
64KB/s after you have sent the
first Gbits of data.


If I were building an adriod app I'd do as follows:

1) Cache as much as possible when bandwidth is high and cheap
    Most phones have dual access - when they come into WiFi range
pro-actively cache as much as possible

    If you assume that the cost of sending data is a few hundred times
the cost of caching the data
    then you won't go far wrong


2) When you get congested weigh every byte on golden scales.

Do not send HTML with all those unnecessary headers:

Be proactive - It will be years before the standards change and HTML
is dumped for radio access - the good
reactive applications will use internal non-standard protocols.


/Joe



> The problem seems to be there rather
> than the language you write your sever. It occurred to me that you
> might benefit from using Jabber/XMPP. Googling I found some iOS jabber
> clients http://code.google.com/p/xmppframework/ and the cannonical
> jabber server is written in Erlang.
>
> Regards,
>
> 2011/7/12 Matthew Hillsborough <matthew.hillsborough@REDACTED>:
>> 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
>>
>>
>
>
>
> --
> Ale.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list