[ Главная · Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
Форум » СИМУЛЯТОР ПУЛЬТА ДИСПЕТЧЕРСКОЙ ЦЕНТРАЛИЗАЦИИ "НЕВА" » Эксперименты в симуляторе » Пытаюсь замутить свой симулятор.
Пытаюсь замутить свой симулятор.
V9Дата: Вторник, 26.11.2019, 11:02 | Сообщение # 1
Станционный диспетчер
Группа: Пользователи
Сообщений: 67
Награды: 2
Репутация: 0
Статус: Offline
Но так как опыта мало, шанс на успех - меньше процента. Тут я планирую держать общество в курсе того, как продвигается работа. Пока что принимаю решение что каждый день не меньше часа, но не более 2 часов буду тратить на программирование, но до нового года. Там будет решено, продолжать или нет, и в каком темпе, если "да".
 
Планирую, что это будет сервер, к которому люди смогут подключаться, и где они смогут совместно играть на полигоне 

Пока что вчера разбирался с системой версионирования Fossil SCM, а так же читал доки по созданию сервера. В гайдах описывается, что при создании подключения надо  создавать отдельную нить Thread на  каждое подключение, точнее даже две нити - на чтение и на  передачу. Однако проведенные эксперименты показали что хорошо действует метод available(), который возвращает 0, если от клиента еще не пришла инфа, и больше нуля, если от клиента что-то поступило. Т.е. можно обойтись двумя нитями - первая будет принимать подключения и передавать второй, а вторая - бегать по списку подключений и проверять - "а что там от кого пришло?"

Так же я проверял нагрузку процессора. Если бегать без конца, грузится процессор. Но если тормозить, останавливать его, на 1..4 миллисекунды, то он все равно грузится (т.е. остановки в реальности не происходит, он бегает внутри по циклу где-то), а вот с 5 миллисекунд начинается честная остановка. При этом, если ставить задержку в 5 миллисекунд, то он останаливается на 15 миллисекунд. При постановке на 15 мс, все равно 15 мс. Дальнейшие эксперименты показали, что остановка квантуется с точностью в 15.5 миллисекунд (15, 31, 46 и т.п.). 1000 / 15 ≈ 65 обходов в секунду. Задержка ответа 15,5 мс - это будет самая худшая задержка, среднее время задержки ответа - примерно 8 мс.

Добавлено (26.11.2019, 18:43)
---------------------------------------------
Сделал самый первый вариант сервера. Правда, пока, он принимает коннект, отдает инфу и вылетает, т.к. основной цикл опроса и обработки не сделан и к нему я даже не приступался. С удивлением узнал, что нет возможности узнать, клиент "живой" или давно "умер". И что данную проблему выясняют тайм-аутом. К примеру веб-сервер Апач ждет 5 секунд и закрывает соединение. Убил много времени на выяснение этого вопроса.

Добавлено (27.11.2019, 10:27)
---------------------------------------------
Сделал главный цикл сервера по обходу подключений, затестил. Сервер держал одновременно 16366 коннектов, что более чем "дофига" на данном этапе. При этом, формально, я запускал тест на этом же компе, так что я не  знаю, где тут проблема - в операционке, тесте или в сервере.

Добавлено (28.11.2019, 15:43)
---------------------------------------------
Гонял под высокими нагрузками, но на том же компе. Для подключения хватает 0.5 миллисекунды. Выяснил для себя, что закрытое с обоих концов (приложение-сервер и приложение-клиент) соединение в системе "висит" еще 120 секунд. Зачем занимает место - малость не очень понятно, т.к. повторно использовать его не получится, хотя "висит" открытым вот вроде для этого "повторного использования". Непонятная загадка.
Сделал буферизированние входящих данных, но не доотладил, т.к. время кончилось. smile

Добавлено (29.11.2019, 21:16)
---------------------------------------------
Отладил поступление данных во входящий буфер; нашел и ликвидировал ошибку. которая затрудняла "размыкание" старых подсоединений. С ошибкой это получилась бы со скоростью 6 коннектов/секунда.

Добавлено (30.11.2019, 19:01)
---------------------------------------------
Потратил время, пытаясь ускорить процесс коннекта, но никаких успешных результатов не добился. "Слишком ранняя оптимизация - зло!"(С)

Добавлено (01.12.2019, 22:00)
---------------------------------------------
Час пытался написать первичный анализатор входящего потока данных серверу.

Добавлено (02.12.2019, 20:00)
---------------------------------------------
Сегодня ставил блокировку на тот случай, если "левый" клиент пришлет большой и бессистемный блок данных. А кроме того, рассматривал ситуацию, если клиент не принмает данные: у меня нет возможности выяснить это заранее, а нить исполнения нельзя блокировать, т.к. она одна. Получился невероятный костыль, но, думаю, должен будет рабоать

Добавлено (03.12.2019, 22:02)
---------------------------------------------
Начал писать парсер входящего запроса. За час добавил 61 строку кода.

Добавлено (04.12.2019, 22:03)
---------------------------------------------
Зачатки парсера сделаны, сегодня писал "револьверный" отсылатель данных. Как ни крути, придется создать несколько нитей отправки данных и четко контролировать скорость отправки, чтобы вовремя "прибивать" зависшие соединения. За час добавлено еще 72 строки кода.

Добавлено (05.12.2019, 06:13)
---------------------------------------------
Сегодня только разбирался с созданием, поддержкой и объединением ветвей (branch) в системе версионирования fossil. Было достаточно сложно для понимания "с нуля", но вроде разобрался. По крайней мере итоговая картинка ветвей у меня получилась та, что я хотел видеть в начале разбирательств.

 
Форум » СИМУЛЯТОР ПУЛЬТА ДИСПЕТЧЕРСКОЙ ЦЕНТРАЛИЗАЦИИ "НЕВА" » Эксперименты в симуляторе » Пытаюсь замутить свой симулятор.
  • Страница 1 из 1
  • 1
Поиск: