@rouuor

TCP. Можно ли ужимать ReceiveTimeout со стороны сервера до миллисекунд?

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

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

Поэтому сообщения аналитики должны отправляться как можно быстрее, а если интернет у пользователя слишком медленный, то просто не отправляться никак.

Из всего этого, в качестве протокола выбран TCP, а ReceiveTimeout (он задается на сервере) нужно как можно сильнее ужать.

Макс. вес одного сообщения (содержимое буфера) - 1 КБ.

Я пробовал отправлять такие сообщения с ноутбука, подключенного по Wi-Fi (тариф очень бюджетный, и повреждена антенна в ноутбуке), ReceiveTimeout был всего 1 миллисекунда (!), однако все 100 сообщений дошли до сервера, и он вернул ответ на каждое из них (содержимое ответа весит вообще 2 байта - "O" и "K").

Но ясно, что это слишком поверхностный тест. Так вот какой ReceiveTimeout в этой ситуации будет адекватным?
  • Вопрос задан
  • 373 просмотра
Пригласить эксперта
Ответы на вопрос 4
@res2001
Developer, ex-admin
Отправляйте по UDP и не парьтесь с ответами - это же не критически важный функционал - дойдет, хорошо, сервер учтет, не дойдет - пофигу.
Ответ написан
Комментировать
@yaror
10 лет в мобильном телекоме
Согласен с res2001 .
Данные, для которых критична оперативность доставки, следует отправлять по UDP.
Или, если настолько критично поддержание сессии и нет желания реализовывать сессии самостоятельно, то по SCTP.

Выкручивание же таймаутов TCP до околонулевых значений приведёт, наоборот, к тому, что при малейшем возмущении на пути прохождения трафика начнутся постоянные ретрансмиты, и передача данных встанет вообще.
Не предназначен TCP для оперативной, в реальном времени, передачи данных! Его задача - гарантированно доставить данные хоть когда-нибудь.
Ответ написан
Комментировать
@John_Nash
coder
Почему проблемы клиента (медленный интернет) волнуют сервер? Это не его задача. Клиент должен сам определять актуальность полученных данных
Ответ написан
Комментировать
@GoldGoblin
Отправлять аналитику в другом потоке и скорость работы утилиты не пострадает. Или я что то не так понял?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы