Hi Richard:

In message
<CALwJ=mwdftrt0jwsehgxfpjedc+k16trhxgyy4xsajy_4wp...@mail.gmail.com>,
Richard Hipp writes:
>On 12/22/17, John P. Rouillard <rouilj@**********> wrote:
>> I am currently running 5
>>
>>   nc www4.fossil-scm.org 80
>>
>> processes and sending no input.
>
>Ah hah!
>
>I think the problem is this code:
>http://www4.fossil-scm.org/artifact/9694a7dc?ln=1855-1858
>
>That connection rate throttler is code that predates Fossil.  I copied
>it from CVSTrac.  It is present in the very first check-in of Fossil
>(2007-07-21).
>
>MAX_PARALLEL is currently set to 2, which is a ridiculously low
>number.  I have raised it to 50 on www4.fossil-scm.org and restarted
>that server.  I should probably raise it to 1000 or so.  And instead
>of sleeping, I'll just block until children die off.

Yup. I ran 55 nc's and accessing the timeline hung for almost a minute.
I have dropped it back to 5 and access is immediate.

>This problem only comes up when running "fossil server" with direct
>connections to the outside, and rogue outsiders starting up
>connections and just sitting on them.

For example an nmap scan.

>People using a reverse proxy (ex: nginx) won't see the problem
>because the reverse proxy never sits on a TCP/IP connection.
>
>Give me a few minutes to come up with the best solution.  Suggestions
>from the mailing list are also welcomed.

Well since reverse proxy servers use a client idle setting, would I be
crazy to suggest the same for fossil?

Allow an admin settable client idle timeout. For this example make it
10 seconds. When a client connects:

  1 start a 10 second timer. If the client sends no data,
    the connection is closed in 10 seconds
  2 if the client sends data, the timer is disabled and
    * if the server can respond to a command (e.g. clone), it will
      respond with no more timers
    * if the server doesn't have a complete command yet, it starts a
      new 10 second timer and goes back to (1)

A bad actor can still send one byte every 10 seconds and possibly
trigger the connection rate throttler.

To guard against this, maybe a max time parameter. If the total time
of the client connection is greater than the max time and the server
has not been able respond to any request the connection is terminated.

As soon as the fossil server has enough input to start
calculating/sending data to the client the max time timer is disabled.
This should allow a server to respond to a long duration request.

Thoughts?

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to