Добрый день.
В функции ngx_epoll_process_events() есть такой участок кода:
for (i = 0; i events; i++) {
c = event_list[i].data.ptr;
instance = (uintptr_t) c 1;
c = (ngx_connection_t *) ((uintptr_t) c (uintptr_t) ~1);
rev = c-read;
if (c-fd == -1 ||
Всем привет.
Как передать доменное имя джейбосу, и как его получить?
Сейчас сервер запущен как демон коммандой ./standalone.sh
Конфиг файл, вернее его часть
location ~ /myapp/ {
proxy_pass http://127.0.0.1:8080;
}
пытался получить имя домена, по которому
Дык установи заголовок Host в что тебе надо... :)
2013/9/27 Vurtatoo nginx-fo...@nginx.us
Всем привет.
Как передать доменное имя джейбосу, и как его получить?
Сейчас сервер запущен как демон коммандой ./standalone.sh
Конфиг файл, вернее его часть
location ~ /myapp/ {
On Fri, 27 Sep 2013 16:29:50 +0400
Dmitry Shurupov dmitry.shuru...@flant.ru wrote:
Всем привет!
Представляю вниманию сообщества модуль nginx-http-rdns, реализующий
простой механизм контроля доступа по доменному имени клиента (имя
определяется по результатам выполнения обратного
On Fri, 27 Sep 2013 16:52:40 +0400
Dmitry Shurupov dmitry.shuru...@flant.ru wrote:
On 27.09.2013 16:50, Peter B. Pokryshev wrote:
Привет. Нет обратки - значит бот?
Далеко не факт.
Я про тоже, а в чем защита от ддоса?
Вот от ддоса:
https://github.com/kyprizel/testcookie-nginx-module
On 27.09.2013 17:02, Peter B. Pokryshev wrote:
Я про тоже, а в чем защита от ддоса?
Вот от ддоса:
https://github.com/kyprizel/testcookie-nginx-module
Да, этим мы тоже пользуемся :-)
Нет утверждений, что nginx-http-rdns — самодостоточное решение защиты от
DDoS'а. Может использоваться как одна
Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из
своих структур и не будет по нему отслеживать события.
Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
тайм-аута либо по получении nevent событий, воркер просыпается и в цикле
перебирает эти
Hello!
On Fri, Sep 27, 2013 at 11:32:20AM -0400, megalodon wrote:
Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из
своих структур и не будет по нему отслеживать события.
Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
тайм-аута либо по
On Friday 27 September 2013 19:32:20 megalodon wrote:
Но после закрытия дескриптора, ядро автоматически удалит этот дескриптор из
своих структур и не будет по нему отслеживать события.
Ход событий в общем: воркер блокируется на epoll_wait(), по истечении
тайм-аута либо по получении nevent
Получается, что если в течение 1мс пришли 2 запроса, то второй будет
дропнут,
даже если в конфиге будет прописано 2000r/s?
Только при условии, что burst был исчерпан.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,10518,243214#msg-243214
Пытаюсь вникнуть в мысль: Мы могли закрыть соединение до того, как
добрались до обработки событий. Но где в промежутке между epoll_wait() и
итерацией цикла, в которой мы обрабатываем событие то место, где мы можем
потенциально закрыть сокет?
events = epoll_wait(ep, event_list, (int) nevents,
Все, осознал: воркер, получив очередной event_list[] и обрабатывая некоторое
событие может закрыть также и другой дескриптор, связанный с обрабатываемым,
причем событие с этого другого закрываемого дескриптора также могло попасть
в этот event_list[], и пока мы до него доберемся, структура, которая
On Friday 27 September 2013 21:26:13 megalodon wrote:
Все, осознал: воркер, получив очередной event_list[] и обрабатывая
некоторое событие может закрыть также и другой дескриптор, связанный с
обрабатываемым, причем событие с этого другого закрываемого дескриптора
также могло попасть в этот
13 matches
Mail list logo
