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

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

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

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

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

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

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

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