Answer the question
In order to leave comments, you need to log in
TCP. Is it possible to shrink ReceiveTimeout from the server side to milliseconds?
You need to implement an analytics server. Your own. For those who don't know, these are statistics of user actions in the application, which developers can analyze and make UX more perfect, also helps to track bugs, etc.
Only I have not a simple application, but a utility, for some users its performance is very critical, literally up to hundreds of milliseconds.
Therefore, analytics messages should be sent as quickly as possible, and if the user's Internet is too slow, then simply not be sent at all.
From all this, TCP is chosen as the protocol, and ReceiveTimeout (it is set on the server) needs to be compressed as much as possible.
Max. weight of one message (buffer content) - 1 KB.
I tried to send such messages from a laptop connected via Wi-Fi (the tariff is very low cost, and the antenna in the laptop is damaged), the ReceiveTimeout was only 1 millisecond (!), however, all 100 messages reached the server, and it returned a response to each of them (response content generally weighs 2 bytes - "O" and "K").
But it is clear that this is too superficial a test. And so what ReceiveTimeout in this situation will be adequate?
Answer the question
In order to leave comments, you need to log in
Send via UDP and don't bother with responses - this is not a critically important functionality - it will come, okay, the server will take it into account, if it doesn't reach - don't care.
Agree with res2001 .
Data for which speed of delivery is critical should be sent over UDP.
Or, if maintaining a session is so critical and there is no desire to implement sessions on your own, then via SCTP.
Twisting the TCP timeouts to near-zero values will, on the contrary, lead to the fact that at the slightest disturbance in the traffic path, constant retransmits will begin, and data transmission will stop altogether.
TCP is not intended for operational, real-time data transfer! Its task is to guarantee the delivery of data at least someday.
Why do client problems (slow internet) worry the server? It is not his task. The client must determine the relevance of the received data
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question