|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
11.04.2018, 16:58 | #1 |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
Алгоритм асинхроной обработки TCP
Имеется такой цикл обработки TCP сервера
Код:
Что бы Вы суда еще добавили/ изменили чтоб добиться максимальной стабильности работы цыкла? Крайне благодарен за ответы. И простите меня за предыдущую портянку. |
11.04.2018, 16:59 | #2 |
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
Лучше выложите проект целиком.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . |
12.04.2018, 09:43 | #3 |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
Как только соберусь силами, немного его облагорожу и выложу.
Там вроде все работает (опираясь на многочасовые тесты). Вопрос только в стабильности. Который наверно решить только разбросом клиентов на н-количество серверов. Чтоб когда падал один, терялась часть активности клиентов и перенаправляло их на свободный сервер. В общем, интересует стабильность. чтоб максимально (насколько это возможно) обрабатывать или хотя-бы детектировать ошибки.. Чтоб сервера-менеджеры (которые мониторят состояние серверов-обработчиков) в крайнем случае вступали в силу и перенаправляли пользователей, перезапускали упавшие, детектили их работоспособность и все в таком духе. Но пока я бомжара, надо максимум стабильности с одной железки. Код как только, так сразу. Спасибо за отклик. |
12.04.2018, 11:05 | #4 | |
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
vova65 доводить вы будете ещё очень долго.
Насколько помню Брукс советуют выпускать проект как только число обнаруженных ошибок в день станет падать. Ибо конкуренты не ждут. Программа вещь детерминированная и многочасовые тесты не являются показателем. Поведение программы зависит от воздействия и окружающей среды. В одних условиях она может работать как часы, в других условиях она будет постоянно падать. Что это значит? 1) Эффект лаборатории. Пока у вас программа в стендовых испытаниях. Вы создали её домашние тепличные условия как только она выходит в мир начинаются непредвиденные отказы. Как практик вам советую начинайте тестировать на 2-х железках. Это совершенно изменит поведение программы. Появляется ошибки которых раньше не было. 1.2) Фрагментация памяти. При последовательном коде она не возникает, а вот при асинхронном шансы нарваться становятся больше. Особенно это проявляется когда у вас будет несколько машин, а не как сейчас пока одна. Правда у вас пока этого не разглядел - может есть, может нету. 2) Нагрузочное тестирование. В реальных условиях у вас будет несколько подключений. Соответственно надо понимать как программа будет тормозить, а судя по таймайтам она будет тормозить. Вылетать. Причем может на 10 подключениях, а может на 100 а может и 10 000. Большые объемы передачи за рас. Много файлов, много сообщений. 3) А что будет с вашей программой если вдруг сеть начнёт терять сетевые пакеты? А ведь на обычном ПК пакеты не теряются днями. Когда как в приделах сети-города нарваться на потерю пакета можно в течение 5 минут. А при выходе в интернет и того чаще. Как минимум это приведёт к отваливанию клиентов. И придётся на сервере чистить зомби подключения. А клиентам держать несколько соединений открытыми. Я увидел код с потоками. Но не увидел где у вас синхронизация. Как минимум насторожил вызов одного класса из другого. Выделение памяти у вас соответствует RAII? Вообще выделять и освобождать память лучше в главном потоке. Правда насколько понял это фоновый поток? Тогда в вашем случае допускаю что можно и в фоновом выделять, освобождать. На вашем мести я бы разбил большой код на функции: 1) Во-первых такой код будет работать быстрее. 2) Во-вторых его проще протестировать. Почему тесты? Тесты это один из способов борьбы с детерминированностью программы. В обычных условиях у вас программа не заходи в определённые ветки кода. Ваша задача прогнать по всем веткам условий, кейсов. Тогда можно будет гарнировать, что она стабильна: что она не падает и корректно отрабатывает при приходе внешних ошибок. Это конечно не панацея, но отлавливает большое число ошибок. Цитата:
И защита от дурака. Если что-то может случиться то это непременно случится. Что такое защита от дурака? К примеру двойная проверка перед удалением файлов/сообщений не знаю что у вас там. Или вывести на экран предупреждение о изменении настроек. Черный и белый список пользователей и/или IP. Правда это уже информационная безопасность нежели стабильность.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . |
|
15.04.2018, 00:42 | #5 | |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
Большое спасибо за ответ.
Не вникал сильно в реализации менеджера памяти что виндового, что делфового. В чем там особенность? Память (основные буферы) выделяю при старте сервера и использую самописный, незамысловатый механизм управления состоянием(занят/свободен) буферов. Есть какие-то удобные и весьма функциональные инструменты для такого тестирования? А то с дуру написал своего клиента с разными сценариями работы. чтоб програть сервер по всем закаулкам логики. Цитата:
Если обобщенно и в двух словах о TCP. Иначе, насколько я помню, там еще прилично нюансов с порядком пакетов, с долгим путешествием пакета который отправителем перешел в состояние потерянного и т.д, и т.п. По поводу потоков, там их пока два, для GUI и поток для обработки сети. Вроде сильной синхронизации пока не нужно. Обратится к убитому потоку никто не должен (если поток какой-то магией не слетит). А порядок записи-чтения данных в текущих моментах не нужен, коль не провтыкал что-то. С проще, согласен. Насчет быстрее, CALL и перегон регистров в/из стек/а быстрее чем JMP? |
|
15.04.2018, 01:03 | #6 |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
Чем можно тестировать WebSocket сервер?
Ибо у браузерах при малой задержке одно из таких извращений не шибко работает. Код:
Отсюда и вопрос, чем бы лучше это все добро тестить? Ибо в таком варианте лиса, действительно лиса со всей ее хитростью. Тость, некоторое время все работает нормально, потом скорость подключений/отключений падает. Уже аж подустал мучить снифер, систему логирования шагов и данных приложенния и думать где я дурак да что не учел. |
15.04.2018, 01:21 | #7 |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
По делфи еще.
Как ловить ошибки памяти, насколько надежны оператива, шина, процессор. Насколько велик шанс что где-то в этой чудной троице байт 01 вдруг станет 02? Как такое хотя бы отловить? Допустим есть код Код:
Хоть это наверно и дико малій шанс, но все же. Как его определить, как побороть? Лично у меня мысли только о доп проверках, о доп переменных, сверка входных и выходных данных. В делфи для отлова исключений по поводу ошибок памяти только try except? И ошибки только при обращении за приделы границ, не к своим данным. Где про это кратко да информативно можно почитать? Последний раз редактировалось vova65; 15.04.2018 в 01:25. |
15.04.2018, 01:28 | #8 |
Пользователь
Регистрация: 05.06.2011
Сообщений: 48
|
DDOS атаки.
Со стороны сервера все что можно это неведомой магией определять подозрительные пакеты, не обрабатывать их и экономить исходящий трафик? А в случае загрузки сетевого канала от DDOS атаки, мерятся тем у кого канал толще?) Или есть более разумные методы борьбы? |
15.04.2018, 12:41 | #9 | ||||
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
Цитата:
Цитата:
Цитата:
Проблема в том что отвал клиента происходит если вообще то через 0٫5-2 часа. Для пользователя это будет выглядеть как зависшая программа. А на сервере просто будет висеть клиенты вернее они там будут копиться и копиться. В большой функции оптимизатор не может разложить все данные по регистрам. Поэтому при jmp у вас будет ещё больше перегонов регистров в/из стек/а. Цитата:
А что касается единичного сбоя одного бита. То вероятность отказа 1 раз в 10 лет для серверной памяти ECC коррекцией. Раз в 10 лет можно и компьютер перезагрузить. А для обычной около 1 года. В научных целях применяют сохранение состояние на диск и двойной расчёт что-бы сверить результаты. А для вашей программы просто установить срок непрерывной работы 1 год. А после 1 час на профилактику - выключить компьютер включить компьютер.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . |
||||
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Бинарные деревья. Итеративный алгоритм обработки | now2 | Паскаль, Turbo Pascal, PascalABC.NET | 6 | 16.10.2014 07:28 |
Алгоритм обработки графических данных в ПК | Notik | Помощь студентам | 5 | 16.12.2012 22:29 |
Алгоритм обработки матрицы | max_scotch | Помощь студентам | 3 | 15.05.2012 10:32 |
TCP/IP параллельной обработки запросов | zhenya.ya | C/C++ Сетевое программирование | 0 | 24.04.2011 21:31 |