Нужен комментарий эксперта о самой быстрой связи для приложения .net

Question

Я хочу добиться максимально быстрой и масштабируемой связи между несколькими серверами. Для этой цели я разработал собственный сервер сокетов TCP с ( IOCP ), так как думаю, что это будет самая быстрая связь в .NET, но я не знаю, происходит ли сбой при высокой нагрузке Мое решение - самый быстрый канал связи для приложений .NET. Есть ли какое-нибудь решение с открытым исходным кодом для удовлетворения моих потребностей?

Какой самый быстрый, масштабируемый и надежный канал связи в .NET Applications?

Answer 1

Существует множество факторов, влияющих на производительность сетевого приложения, начиная с архитектурных решений, выбора протокола, перегрузки сети, вплоть до сериализации сообщений, выделения памяти и т. Д. Не существует способа «один размер подходит всем» сетевого взаимодействия, которое делает приложение автоматически масштабируемым, устойчивым к высоким нагрузкам и т. д.

Протоколы нижнего уровня имеют меньше накладных расходов, это правильно. Но протоколы более высокого уровня могут быть намного лучше для некоторых случаев использования, потому что они уже предоставляют некоторые функции, которые в противном случае вам пришлось бы реализовать самостоятельно. И, как я уже сказал, протокол не единственное, что влияет на производительность.

Вам необходимо собрать свое требование, определить узкие места, спроектировать соответствующую архитектуру, выбрать протокол на правильном уровне абстракции, а также профиль, профиль, профиль.

Answer 2

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

Конечно, решение также зависит от того, какие технологии вам удобны;Написание масштабируемых TCP-серверов - сложная задача, и вам необходимо профилировать свое решение на всех этапах разработки с помощью реалистичного количества тестовых клиентов и имитируемого потока данных и т. д. Написание пользовательских надежных или полунадежных протоколов UDP еще сложнееВполне возможно, что «менее быстрое» решение подойдет и будет проще в реализации, поскольку кто-то другой сделает всю тяжелую работу за вас.Опять же, единственный способ узнать это - описать то, что напоминает реалистичное представление вашей проблемы.