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

Question

[rouuor]

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

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

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

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

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

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

Но ясно, что это слишком поверхностный тест. Так вот какой ReceiveTimeout в этой ситуации будет адекватным?

Answer 1

[res2001]

Отправляйте по UDP и не парьтесь с ответами - это же не критически важный функционал - дойдет, хорошо, сервер учтет, не дойдет - пофигу.

Answer 2

[Ярослав]

Согласен с res2001 .
Данные, для которых критична оперативность доставки, следует отправлять по UDP.
Или, если настолько критично поддержание сессии и нет желания реализовывать сессии самостоятельно, то по SCTP.

Выкручивание же таймаутов TCP до околонулевых значений приведёт, наоборот, к тому, что при малейшем возмущении на пути прохождения трафика начнутся постоянные ретрансмиты, и передача данных встанет вообще.
Не предназначен TCP для оперативной, в реальном времени, передачи данных! Его задача - гарантированно доставить данные хоть когда-нибудь.

Answer 3

[John_Nash]

Почему проблемы клиента (медленный интернет) волнуют сервер? Это не его задача. Клиент должен сам определять актуальность полученных данных

Answer 4

[Евгений]

Отправлять аналитику в другом потоке и скорость работы утилиты не пострадает. Или я что то не так понял?

Comments

[Александр Тер]

Ну тут сразу возникает целый ворох проблем от синхронизации до расходования памяти. В данном случае самым оптимальным будет отправка UDP