Arduino Mega Server

Alex · Сообщение **Alex** » Пт авг 07, 2015 8:41 pm

Мы попадаем на полноценный сайт, и таких сайтов может быть сотни для каждого чайника и каждого цветка (при желании).

Автоматическое управление это само-собой (это обычный микроконтроллер).

Ложка дёгтя в этой бочке мёда заключается в том, что настраивать всё под себя вам придётся самому, а для этого нужно много знать и понимать. Пока это не для всех, в будущем, возможно появятся стандартные конфигурации или сервисы по разработке решений на заказ.

Alex · Сообщение **Alex** » Пт авг 07, 2015 9:03 pm

Нашёл обсуждение проблемы на итальянском: ссылка.

Насколько я понял, они сделали примерно то же, что и я. Только немного не доделали. Так?

Сейчас интересно в чём причина оставшейся 3-х секундной задержки. В общем всё работает, но как-то неаккуратненько.

olehs · Сообщение **olehs** » Сб авг 08, 2015 2:25 am

Alex, прочитал статью на geektimes. Не могу поддержать обсуждение там, т.к. не зарегистрирован, но вынужден согласиться с mifki.

Проблема не в библиотеке Ethernet, а в ограничении самого чипа W5100. Если заглянуть в его даташит
(https://www.sparkfun.com/datasheets/Dev ... v1_1_8.pdf), то там написано: Supports 4 independent sockets simultaneously . Это согласуется со значением MAX_SOCK_NUM. А вот современные браузеры, пытаются качать все сразу в большем к-ве потоков (Chrome, кажется, в 6 потоков, а Firefox во все 15).

Соответсвенно, некоторые потоки получают отказ в подключении. Но в TCP есть такая замечательная вещь, как TCP retransmission. Это попытка повторной отправки пакета через определенный таймаут. Вот отсюда мы получаем задержку в 3 сек - это Default Retransmission Timeout в Windows (см. напр. https://msdn.microsoft.com/en-us/librar ... 2147217396).

Т.е. что получется: 4 потока занимают 4 сокета, а 5-й и 6-й получают отказ и ждут 3 сек. Через 3 сек. они могут получить сокет, а может уже кто-то другой более шустрый все занял - тогда опять ждать 3 сек.

Вот как-то так )

Alex · Сообщение **Alex** » Сб авг 08, 2015 7:07 am

Т.е. что получется: 4 потока занимают 4 сокета, а 5-й и 6-й получают отказ и ждут 3 сек.

Не всё так просто. На диаграммах видно, что есть куча отработанных и ничем не занятых сокетов.

Идея с TCP retransmission интересна, по крайней мере хоть какое-то объяснение 3-х секунд.

Кто нибудь может по шагам описать, что происходит с момента посылки запроса браузера до начала зелёной линии ответа сервера?

uni · Сообщение **uni** » Сб авг 08, 2015 8:15 am

Кто нибудь может по шагам описать, что происходит с момента посылки запроса браузера до начала зелёной линии ответа сервера?

Можно попробовать сниффер. По идее его нужно было с самого начала как инструмент использовать. Там, возможно, будет более полная информация о пакетах и отказах. Нужно на торрентах найти самый продвинутый сниффер и понаблюдать за обменом данными. Браузерная диаграмма загрузки - это так, для поверхностной оценки.

Вы без сниффера разбор заголовков делали?

Alex · Сообщение **Alex** » Сб авг 08, 2015 9:31 am

В своей работе я использовал инструменты разработчика, встроенные в браузер.

Проблема в том, что я понимаю механизм взаимодействия процентов на 90%. И я уверен, что для решения проблемы достаточно 3-х вещей:

1. Чёткое понимание механизма взаимодействия (достаточно теории).
2. Исходные файлы библиотеки (есть в наличии)
3. Диаграммы отражающие временные зависимости.

Из этого пазла мне не хватает только чёткого понимания теории (10%). В частности, что конкретно происходит в начале и конце длинной линии. В чём причина того, что висящий запрос вдруг поступает в обработку. Что является триггером и что блокирует обработку.

Сейчас у меня 2 предположения, это незакрывающиеся сокеты и проблемы с работой кеша W5100.

uni · Сообщение **uni** » Сб авг 08, 2015 9:39 am

И это прочли и поняли: Веб-сервер за 5 минут на базе PIC и W5100 ? Можно обратиться к автору этой статьи, думаю, он сможет что-нибудь подсказать.

Ещё статья с хабра: Подключаем новенький чип от WIZnet: W5500. IP для маленьких вещей. Часть 1 . Можно попробовать обратиться и к этому автору.

Alex · Сообщение **Alex** » Сб авг 08, 2015 9:46 am

Да, я это прочитал. Что-то понял, что-то — нет и это не удивительно потому, что статья тянет на докторскую диссертацию. И даже вопрос уже задал, но коллега PEACE_dez... ничего не ответил. О причине подобного я могу только догадываться. Моё предположение, что ответа у него нет.

Вторую статью сейчас почитаю.

olehs · Сообщение **olehs** » Сб авг 08, 2015 10:08 am

Alex писал(а):
Т.е. что получется: 4 потока занимают 4 сокета, а 5-й и 6-й получают отказ и ждут 3 сек.
Не всё так просто. На диаграммах видно, что есть куча отработанных и ничем не занятых сокетов.

Идея с TCP retransmission интересна, по крайней мере хоть какое-то объяснение 3-х секунд.

Кто нибудь может по шагам описать, что происходит с момента посылки запроса браузера до начала зелёной линии ответа сервера?

Диаграммы вы строите со стороны браузера, а я говорю о сокетах со стороны W5100.

Для проверки я создал тестовую страничку, которая заставляет браузер поднять ровно 5 коннектов. на Arduino я использовал оригинальные либы. Диаграмма из Хрома во вложении.

А вот дамп сниффера пятого подключения (test4.html)

Код: Выделить всё

No.     Time                          Source                Destination           Protocol Length Info
     19 2015-08-08 09:59:19.921557000 192.168.1.1           192.168.1.210         TCP      66     62009→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
     21 2015-08-08 09:59:19.922136000 192.168.1.210         192.168.1.1           TCP      60     80→62009 [RST] Seq=1 Win=0 Len=0
    105 2015-08-08 09:59:22.920998000 192.168.1.1           192.168.1.210         TCP      66     [TCP Retransmission] 62009→80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
    108 2015-08-08 09:59:22.921868000 192.168.1.210         192.168.1.1           TCP      60     80→62009 [SYN, ACK] Seq=2183659801 Ack=1 Win=2048 Len=0 MSS=1460
    110 2015-08-08 09:59:22.922013000 192.168.1.1           192.168.1.210         TCP      54     62009→80 [ACK] Seq=1 Ack=2183659802 Win=64240 Len=0
    113 2015-08-08 09:59:22.922992000 192.168.1.1           192.168.1.210         HTTP     534    GET /test4.html HTTP/1.1 
    114 2015-08-08 09:59:23.065453000 192.168.1.210         192.168.1.1           TCP      86     [TCP segment of a reassembled PDU]
    115 2015-08-08 09:59:23.065546000 192.168.1.1           192.168.1.210         TCP      54     62009→80 [ACK] Seq=481 Ack=2183659834 Win=64208 Len=0
    116 2015-08-08 09:59:23.067075000 192.168.1.210         192.168.1.1           TCP      86     [TCP segment of a reassembled PDU]
    117 2015-08-08 09:59:23.067075000 192.168.1.210         192.168.1.1           TCP      75     [TCP segment of a reassembled PDU]
    118 2015-08-08 09:59:23.067150000 192.168.1.1           192.168.1.210         TCP      54     62009→80 [ACK] Seq=481 Ack=2183659887 Win=64155 Len=0
    119 2015-08-08 09:59:23.067918000 192.168.1.210         192.168.1.1           TCP      63     [TCP segment of a reassembled PDU]
...

По шагам, что происходит:
- браузер запрашивает подключение [SYN]
- получает отказ, т.к. нет свободных сокетов [RST]
- ждет Retransmission Timeout
- перепосылает [SYN]
- успешно подключается и получает ответ

olehs · Сообщение **olehs** » Сб авг 08, 2015 10:18 am

Что можно предложить? Мне приходит в голову пока только одно - оптимизация сайта (AMS) под 4 сокета:

1. В конечной версии нужно слепить все файлы по типам: все *.css объединить в один файл и все *.js
Так браузер будет грузить в 3-х соединениях: страничку, css и js, а 4-ый оставим ему на favicon
2. Убрать со странички явно вставленные <img> и грузить их из Javascript по AJAX уже после загрузки документа, НО ограничиваясь 4-мя одновременными загрузками.

Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server

Re: Arduino Mega Server