5ый семестр / 1. Производственная практика_1 / стащил с работы / Начинающему сетевому программисту _ Хабр

da-nie 11.10.2021 в 18:18

Это приложение будет использовать Win32API

«К тому же в Unix нет никаких WSA-функций.» — это как бы намёк, что другие ОС обходятся и без WSA. :)

0 Ответить

DistortNeo 11.10.2021 в 18:07

Вас спасёт select/poll/epool.

Ага. То есть мало просто перевести сокет в неблокирующий режим, надо ещё и по-хитрому с ним работать. Причём способ получается ещё и системо-зависимый.

См. выше. Сможет и будет отлично работать.

Вы не сможете без танцев с бубнами мультиплексировать операции по сокетам с событиями GUI в одном потоке. Так что да, все операции с сокетами — в отдельный поток + веселуха с межпотоковой синхронизацией.

0 Ответить

da-nie 11.10.2021 в 18:24

Ага. То есть мало просто перевести сокет в неблокирующий режим, надо ещё и по-хитрому с ним работать. Причём способ получается ещё и системо-зависимый.

Вот именно, что системонезависимый. В Windows это тоже будет работать (в отличие от WSA, которые ТОЛЬКО в Windows и есть).

Вы не сможете без танцев с бубнами мультиплексировать операции по сокетам с событиями GUI в одном потоке.

Счего бы это вдруг? ;)

+веселуха с межпотоковой синхронизацией.

Это вообще, обычно, никаких проблем не вызывает.

0 Ответить

DistortNeo 11.10.2021 в 18:39

Вот именно, что системонезависимый. В Windows это тоже будет работать (в отличие от WSA, которые ТОЛЬКО в Windows и есть).

С каких пор в Windows завезли epoll, во FreeBSD — IOCP, а в Linux — kqueue?

Или предлагаете по-старинке через select работать?

С чего бы это вдруг? ;)

Вы вообще представляете, как выглядит очередь сообщений в GUIприложений и как к ней прикрутить сокеты?

Это вообще, обычно, никаких проблем не вызывает.

Пользователь в GUI-приложении нажал на кнопку отмены, нужно остановить операцию по сокету в другом потоке, висящим на select/epoll_wait. Что предложите?

+1 Ответить

da-nie 11.10.2021 в 19:32

Или предлагаете по-старинке через select работать?

Почему бы и нет? Вам же нужна независимость от ОС?

А не через select (и не через WSA) вы покроете почти все UNIXсистемы, но не покроете Windows. С WSA же вы получите всё ровно наоборот — только Windows и всё. Впрочем, тот же Pool есть как WSAPool и вы можете просто сделать макрос замены. При этом код менять не потребуется.

Вы вообще представляете, как выглядит очередь сообщений в GUI-приложений и как к ней прикрутить сокеты?

Единственное, чего я не представляю, так это выдуманные на пустом месте проблемы. :)

Что вам помешает передать требуемые работы с сокетами события потоку? Прямо из GUI, да. А потоку их можно хоть в очередь ставить, хоть сразу исполнять — это уже его дело.

Пользователь в GUI-приложении нажал на кнопку отмены, нужно остановить операцию по сокету в другом потоке, висящим на select/epoll_wait. Что предложите?

Вы в потоке крутитесь в цикле while(true) с внутренним select:

timeval timeout; while true

{

timeout.tv_sec=0 timeout.tv_usec=timeout_us;

long ret=select( 0,&Readen 0,&Exeption,&timeout);

}

Что помешает вам проверить сразу после select какое-либо событие (его можете хоть как флаг сделать, защитив мютексом или критической секцией)?

Кстати, а вы не смотрели, с какой частотой Windows переключает потоки? ;) Думаете, очередь сообщений (вместе с GUI) работает быстрее? Ну-ну.

0 Ответить

DistortNeo 11.10.2021 в 19:54

Почему бы и нет? Вам же нужна независимость от ОС?

Как уже написали в соседнем комментарии, если номер дескриптора больше, чем FD_SETSIZE (который захардкожен в 1024), то вы не сможете поместить его в select . Хорошая переносимость, правда?

Вы в потоке крутитесь в цикле while(true) с внутренним select

А select -у как сообщим, что надо прерваться? Или будем ждать таймаута, что само по себе является плохой практикой?

Кстати, а вы не смотрели, с какой частотой Windows переключает потоки? ;) Думаете, очередь сообщений (вместе с GUI) работает быстрее? Ну-ну.

Как-то раньше игрался: простой пинг-понг событиями между потоками показал что-то вроде 20-30к переключений в секунду. А вот сколько сообщений можно пропустить через очередь сообщений, я не замерял.

Ну а так-то да, логично всю обработку делать в отдельном потоке и не насиловать GUI-поток.

0 Ответить

da-nie 11.10.2021 в 20:10

Как уже написали в соседнем комментарии, если номер дескриптора больше, чем FD_SETSIZE (который захардкожен в 1024), то вы не сможете поместить его в select. Хорошая переносимость, правда?

Вы с этим сталкивались? ;) Нет, серьёзно, вы когда-нибудь ожидали 1024 сокета? Фантазировать, конечно, не запретишь, но всё же, как вам тогда 65535 портов хватает? Мне вот раз в 10 больше надо. :) Ну а почему бы и нет? ;)

А select-у как сообщим, что надо прерваться? Или будем ждать таймаута, что само по себе является плохой практикой?

Кто это сказал, что это плохая практика?

Как-то раньше игрался: простой пинг-понг событиями между потоками показал что-то вроде 20-30к переключений в секунду.

Не совсем.

0 Ответить

DistortNeo 11.10.2021 в 21:37

Вы с этим сталкивались?

Нет, потому что я использую epoll и IOCP.

Кто это сказал, что это плохая практика?

Это плохая практика, потому что если таймаут будет большой, тогда отзывчивость приложения будет низкой. А

если маленький, тогда поток будет постоянно просыпаться по таймауту select, что не есть хорошо.

Не совсем.

А причём тут таймер? ОС не ждёт следующего кванта времени, чтобы стартовать выполнение потока.

0 Ответить

da-nie 12.10.2021 в 17:35

Нет, потому что я использую epoll и IOCP.

Речь о количестве сокетов, а не о ограничениях. Если у вас набирается столько сокетов на один поток, то пора пересмотреть архитектуру приложения.

Аесли маленький, тогда поток будет постоянно просыпаться по таймауту select, что не есть хорошо.

Увас в любом случае потоки будут потреблять процессор. Не этот, так другой. Так что всё это не более, чем собственноручно введённые ограничения. Добавление в очередь асинхронных событий с сокетами тоже не святой дух делает.

Апричём тут таймер? ОС не ждёт следующего кванта времени, чтобы стартовать выполнение потока.

Разбор очереди сообщений привязан к этому таймеру. Если у вас один поток работает, то проблемы не будет, но если несколько, то вот с частотой этого таймера будет происходить их вытеснение. Это очень хорошо видно, если требуется в потоке опрашивать на шине какое-либо устройство чтением из порта с ожиданием готовности (если прерывание не завезли — так бывает). Там будут прелестные лаги во временной диаграмме.

0 Ответить

DistortNeo 12.10.2021 в 18:00

Речь о количестве сокетов, а не о ограничениях. Если у вас набирается столько сокетов на один поток, то пора пересмотреть архитектуру приложения.

Таки не поток, а процесс. Тот же nginx на пару порядков больше соединений может держать, кстати.

У вас в любом случае потоки будут потреблять процессор.

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

Разбор очереди сообщений привязан к этому таймеру.

Ну если у вас всё на sleep-ах сделано, тогда да.

0 Ответить

da-nie 12.10.2021 в 18:06

Таки не поток, а процесс. Тот же nginx на пару порядков больше соединений может держать, кстати.

Ну может и может, вы лично 1024 использовали?

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

Вы невнимательно читаете. Процессор в любом случае будет кем-то потребляться, хоть IDLE, но будет. И беречь в этом случае поток обработки смысла нет — ничего не выиграете.

Ну если у вас всё на sleep-ах сделано, тогда да.

Оно и без них будет идти неравномерно. То бежать, то приостанавливаться.

0 Ответить

DistortNeo 12.10.2021 в 19:09

Процессор в любом случае будет кем-то потребляться, хоть IDLE, но будет.

Энергосбережение? Нет, не слышали.

0 Ответить

da-nie 12.10.2021 в 19:13

Энергосбережение? Нет, не слышали.

Да ладно! :O

То есть, когда сайт сбербанка грузится хрен знает сколько или те же avito, youtube и ozon не стесняются кушать память и процессор в моём firefox, то это нормально, тут ни о каком энергосбережении речи как-то не заходит. :) Да и ОС с остальным ПО всё жиреют и жиреют. Процессор греется от натуги, вытаскивая все эти слои абстракций и прослоек. Но «это другое». :)

0 Ответить

DistortNeo 12.10.2021 в 20:01

Да, и это просто отвратительно. У меня есть и другие примеры, когда криво написанный сетевой софт отжирает в фоне процессорное время, даже если он не используется.

Например, в nxserver сделан epoll_wait с таймаутом 100 мс. Как следствие, он жрёт процессор. За 5 суток сожрал 7 минут процессорного времени. Мелочь, а неприятно.

С x2goserver ещё хуже: скрипт на perl, который раз в 2 секунды запускает несколько других процессов для очистки зависших сессий. Жрёт ещё больше. Частично пофиксил проблему, пропатчив скрипт и увеличив интервал до 120 секунд.

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

0 Ответить

da-nie 12.10.2021 в 20:26

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

А вы проведите такой эксперимент — напишите с ожиданием и на асинхронке. Думаю, результат разницы времени автономной работы ноутбука будет на уровне статистической погрешности (я про nxserver).

0 Ответить

morgot 10.10.2021 в 21:52

Есть хорошая книга - Джонс Энтони, Оланд Джим. "Программирование в сетях Microsoft Windows". Единственная по Winsock 2 , хоть ей лет 20, но в сетевом программировании мало что меняется. Еще есть несколько хороших по первой версии винсок (и где-то временам Windows 95).

0 Ответить

unC0Rr 12.10.2021 в 17:48

Неплохо бы раскрыть также и тему IPv6.

0 Ответить

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

ПОХОЖИЕ ПУБЛИКАЦИИ

6 января 2021 в 13:16

В Windows 10 внедрят единый клиент Outlook вместо Почты и Календаря

7 декабря 2015 в 21:17

Microsoft добавил возможность отключения слежения в версиях Windows 10 для корпоративных клиентов

19 ноября 2013 в 12:02

Рисовалка под Windows на C++, или «Ребята, я тоже ненормальный!» (30+ строк кода)

ЛУЧШИЕ ПУБЛИКАЦИИ ЗА СУТКИ

сегодня в 00:00

Позиция Хабра по происходящему

вчера в 15:59

Отрасль IT в России поставили на паузу

вчера в 19:21

Кризис в России и финансовые вопросы: как не потерять то, что есть

вчера в 13:00

Делаем стреляющего джаггернаута из игры Turok: Evolution с помощью подручных материалов