Асинхронный и синхронный сервер сокетов для приложений реального времени

Question

В настоящее время я разрабатываю сервер сокетов C #, который должен отправлять и получать команды в режиме реального времени.Клиент является устройством Android.В настоящее время требования в реальном времени являются «мягкими», однако в будущем могут возникнуть более строгие временные требования.Допустим, в будущем это может быть отправка команд на кран, который может быть потенциально опасным.

Сервер работает, и, похоже, очень хорошо с моим текущим дизайном синхронных сокетов.У меня есть отдельные темы для получения и отправки данных.Мне интересно, есть ли какая-либо причина для попытки асинхронного подхода к сокету сервера?Может ли это обеспечить большую стабильность и / или более высокую производительность?

Answer 1

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

Просто примечание о реальном времени, если ваши требования в реальном времени не похожи на необходимость гарантировать ответ в x-time, тогда C # и .NET не дадут вам таких гарантий. Это, однако, зависит от ваших текущих и будущих определений «софт». Может случиться так, что у вас случится хорошее время отклика, но не путайте это с настоящими системами реального времени.

Answer 2

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

Answer 3

Если это реальное время, то вы абсолютно хотите, чтобы ваши сообщения были поддержаны очередью, чтобы вы могли доказать временную логику в этой очереди.Это то, что дает вам nio / io-creation-ports / async.Если вы используете синхронное программирование, то вы тратите впустую ваш ЦП, копируя данные из ОЗУ на сетевую карту.

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

Скажем, например, что клиент хотел выполнить атаку DOS.Он подключится и отправит один байт данных.Ваше приложение теперь не сможет получать дальнейшие команды для тайм-аута этого соединения, которое может быть довольно большим.При использовании async вы получите ACK-пакет обратно, но ваш код не будет ожидать полной передачи.

Answer 4

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