<div class="gmail_quote">On Thu, Jun 16, 2011 at 8:55 AM, Bob Ippolito <span dir="ltr"><<a href="mailto:bob@redivi.com">bob@redivi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Jun 15, 2011 at 8:11 PM, József Bérces<br>
<<a href="mailto:jozsef.berces@ericsson.com">jozsef.berces@ericsson.com</a>> wrote:<br>
> Thanks for all the thoughts and suggestions. If I got it right, there were two main branches:<br>
><br>
> 1. Avoid the congestion situation<br>
> 2. Detect and kill/restart the problematic process(es)<br>
><br>
> The problem with these approaches that the Erlang applications are not just playing with themselves but receive input from other nodes. Those nodes can be very numerous and uncontrollable.<br>
><br>
> As an example, just let's take the mobile network where the traffic is generated by millions of subscribers using mobile devices from many vendors. In this case we (1) cannot control the volume of the traffic and (2) cannot make sure that all the devices follow the protocol.<br>

> So there can be situations when we cannot avoid congestion simply because the source of the traffic is beyond our reach.<br>
<br>
</div>The Erlang distribution protocol is only suitable for connecting a<br>
relatively small number of trusted nodes on a LAN.<br></blockquote><div><br>I think I get the jist of it, but could someone quantify, as to how "small" is "relatively small number" here ? Fifty, few hundreds, couple of thousands ? <br>
What is the largest 'Erlang cloud' (i.e. hosts running Erlang processes communicating accross nodes in a cluster), that has been seen ?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


If you were to expertly implement such an application you would have<br>
some Erlang nodes speaking to these mobile devices, but with another<br>
protocol (probably over TCP), and then you would have as much control<br>
as you need over the other details. For example, you can avoid<br>
congestion by rate limiting or refusing to accept new connections.<br>
When the Erlang nodes speak to each other (with or without Erlang<br>
distribution), you also control that protocol and can avoid congestion<br>
there as well.<br></blockquote><div><br>In telecom world such a situation is pretty common, however think of the situation that even to discard a message (due to congestion) that starts a new transaction if I need to determine things like priority, transaction-id or application level session-id etc., I'd have to have the ability to decode that much message in the rate-limiter process, which I think we are saying, will be written in C/C++ and communicating over IP or another protocol. Duplicating the decode logic, I guess would be unavoidable, in most such cases. Or is there a better behavioral pattern someone has figured out ?<br>
</div>
</div>