<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font face="Arial">Hi Fabian,<br>
      <br>
      Unfortunately I don't have control over the protocol itself as the
      devices are made by different manufacturers. However, your email
      did highlight the issue that devices will in very quick succession
      try to re-establish connections potentially causing issues in
      other areas such as our firewalls.<br>
      <br>
      Kind Regards,<br>
      Don<br>
      <br>
    </font><br>
    On 20/09/2011 17:11, Fabian Rothfuchs wrote:
    <blockquote cite="mid:CA9E78DA.1B57B%25fabian.rothfuchs@gmail.com"
      type="cite">
      <div>In your Protocol, I would implement a specific Error that
        &nbsp;might be returned by the server in such burst situations.</div>
      <div>The clients should interpret that error in a way that lets
        them reconnect to the server after a randomly chosen interval.</div>
      <div>This way you immediately eliminate the burst without running
        into the situation where you might get another and another and
        another&#8230;</div>
      <div><br>
      </div>
      <div>A good help for that might be the TR-069 protocol
        specification, which deals with HTTP connections from 1 server
        to millions (!) of clients:</div>
      <div><a moz-do-not-send="true"
href="http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf">http://www.broadband-forum.org/technical/download/TR-069_Amendment-3.pdf</a></div>
      <div><br>
      </div>
      <div><br>
      </div>
      <span id="OLK_SRC_BODY_SECTION">
        <div style="font-family: Calibri; font-size: 11pt; text-align:
          left; color: black; border-width: 1pt medium medium;
          border-style: solid none none; border-color: rgb(181, 196,
          223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in
          0in;"><span style="font-weight: bold;">From: </span> Don
          Schoeman &lt;<a moz-do-not-send="true"
            href="mailto:don@delphexonline.com">don@delphexonline.com</a>&gt;<br>
          <span style="font-weight: bold;">Reply-To: </span> Twisted
          general discussion &lt;<a moz-do-not-send="true"
            href="mailto:twisted-python@twistedmatrix.com">twisted-python@twistedmatrix.com</a>&gt;<br>
          <span style="font-weight: bold;">Date: </span> Tue, 20 Sep
          2011 14:51:26 +0200<br>
          <span style="font-weight: bold;">To: </span> Twisted general
          discussion &lt;<a moz-do-not-send="true"
            href="mailto:twisted-python@twistedmatrix.com">twisted-python@twistedmatrix.com</a>&gt;<br>
          <span style="font-weight: bold;">Subject: </span>
          [Twisted-Python] Protection against flooding<br>
        </div>
        <div><br>
        </div>
        <div>
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          <div bgcolor="#ffffff" text="#000000"> <font face="Arial">Hi
              all,<br>
              <br>
              Before I start digging in the Twisted code, I'd just like
              to bump this off you in case the solution is obvious...<br>
              <br>
              I have a lot of clients having permanent connections to my
              TCP server. These clients are devices that will buffer
              data if it can't connect to the server. I can see a
              possible problem in the future if/when for whatever reason
              there is downtime on my server or the network and all
              these devices start connecting and transmitting their
              buffered data once the server is back up, potentially
              causing server flooding.<br>
              <br>
              What would be a good area to start looking into preventing
              something like this from happening? My first thoughts are
              to simply limit an X number of new connections per minute
              (or per X seconds) and to simply immediately drop new
              connections if it exceeds that limit. (I'd probably
              implement this on Protocol level). Over time the
              connections should theoretically normalise as the buffered
              data on the devices are also limited.<br>
              <br>
              Of course it would be better to not allow the connections
              from being established in the first place if the limits
              are exceeded (will be great for DDOS protection), but I
              have a feeling that might be difficult to achieve.<br>
              <br>
              Any thoughts/tips or even links to examples?<br>
              <br>
              Kind Regards,<br>
              Don<br>
              <br>
              <br>
            </font> </div>
        </div>
        _______________________________________________
        Twisted-Python mailing list
        <a moz-do-not-send="true"
          href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a>
        <a moz-do-not-send="true"
          href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a>
      </span>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Twisted-Python mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a>
<a class="moz-txt-link-freetext" href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a>
</pre>
    </blockquote>
  </body>
</html>