Модератор: Alex
Код: Выделить всё
void serverWorks() {
for (int sock = 0; sock < MAX_SOCK_NUM - 1; sock++) {
EthernetClient sclient = server.available_(sock);
serverWorks2(sclient);
}
} 
Завтра попробую с новой процедурой что вы выложили посмотрим будет работать или нет, а пока мега бегает на старой версии АМС.Alex писал(а):Итак, нормально всё быть никак не может, обязательно вылезет какая-нибудь гадость.
Похоже товарищ olehs был прав и нужно всё-таки довести до ума работу с Ethernet.
Пока в качестве временной меры можно применить костыль:
Вроде бы и скорость не упала и данные стали отправляться. Тестируем и докладываем о результатах. А товарищ olehs и если кто ещё найдётся компетентный думают о том, как это всё-таки привести в нормальный рабочий вид.Код: Выделить всё
void serverWorks() { for (int sock = 0; sock < MAX_SOCK_NUM - 1; sock++) { EthernetClient sclient = server.available_(sock); serverWorks2(sclient); } }
Код: Выделить всё
EthernetClient EthernetServer::available() {
accept();
for (int sock = 0; sock < MAX_SOCK_NUM; sock++) {
EthernetClient client(sock);
if (EthernetClass::_server_port[sock] == _port &&
(client.status() == SnSR::ESTABLISHED ||
client.status() == SnSR::CLOSE_WAIT)) {
if (client.available()) {
// XXX: don't always pick the lowest numbered socket.
return client;
}
}
}
return EthernetClient(MAX_SOCK_NUM);
}Как я понимаю что происходит:Он говорит, что не стоит возвращать первый сокет в подходящем состоянии, а желательно проверить, есть ли в нем запрос. Это позволяет обработать другие сокеты, пока клиент после подключения надумает отправить запрос.
Это понятно. Именно поэтому мне понадобилось меньше минуты, чтобы догадаться куда нужно поставить -1, чтобы всё заработало. Но сейчас вопрос не в этом. Мне бы хотелось получить от вас чёткие ответы по разбору алгоритма выше. Я правильно описал то что там происходит? Конкретно по шагам.Догадываетесь, почему перестали отправляться данные в МД? Сокеты нужны не только серверу
Вот об этом я и твержу уже очень долго. Это КРЕСТ (ХХХ) на нормальной работе, если запросы не единичные.из-за особенности реализации метода available() - следующим может быть обработан не второй по очереди запрос, а только что поступивший на освободившийся первый, т.е. при интенсивной бомбежке сервера браузером - часть запросов на 2-4 сокетах могут игнорироваться очень долго
Это уже сделано. При особом желании можно всё запихнуть в одну страницу и один запрос. Но остаётся ещё проблема с потоковым Ajax-ом.уменьшить кол-во запросов со стороны браузера (склеивание файлов какраз для этого)
В 0.12 версии так и делается, в 0.11 этого не было.Т.ч. желательно в ответ всегда включать заголовок "Connection: close"
вот тут Вы ошиблись.timapple писал(а): Как же работает библиотека Ethernet в режиме сервера:
Скетч в цикле вызывает EthernetServer::available(), в котором:EthernetServer::begin() - открывает все свободные (CLOSED) сокеты на прослушивание (LISTEN)
- EthernetServer::accept() - закрываются ненужные сокеты и проверяется, есть ли хотябы один слушающий сокет. Если таковых нет - вызывается EthernetServer::begin()
- ищется сокет с данными от клиента и возвращается скетчу. Причем, если таких сокетов несколько, то всегда выбирается с минимальным номером, т.е. без учета очередности подключения клиентов. Вот об этом тот самый комментарий XXX
и вот это не совсем корректно. Шансы, что сокет, который только что был переведен в статус LISTEN сразу же (за пару инструкций процессора) получит входящий коннект, да еще и сданными ничтожно малы. Для этого клиент должен попасть своим SYN пакетом четко в это промежуток и сразу же запихнуть данные
- из-за особенности реализации метода available() - следующим может быть обработан не второй по очереди запрос, а только что поступивший на освободившийся первый
Код: Выделить всё
while(1)
if(available()) {
processRequest();
stop();
}