Answer the question
In order to leave comments, you need to log in
And yet, what is better for mobile devices TCP or UDP?
I would like to hear opinions on the pros and cons of both protocols in relation to mobile devices, such as GPS trackers, which use mobile networks (usually GPRS) to transmit information.
UPD : What will happen to the load on the server in cases where this or that protocol is used?
Answer the question
In order to leave comments, you need to log in
We read their description in Wikipedia. We think that there is a GPS. We understand that he should send little information as often as possible, but if some part of the information is lost, then to hell with it - it is no longer relevant.
It makes sense to use UDP in such cases:
1. A single request will be sent to the server and a single response will be received, which will be collected in one packet (it is easier to transfer data than establish a TCP connection)
2. There is a real-time data stream, and in this case loss or delay of a network packet, it is better to lose this data altogether than to resend it (TCP connection will only interfere)
3. Multicast implementations for this protocol are planned (TCP is basically not good)
In all other cases, it is better to use TCP
Terminal independent. Depends on the "application".
You won't get ping/rtt with TCP, but it's easier to "horizontally" scale servers.
With UDP, it is easier to adapt to really bad channels, to avoid billing miracles (you pay for data resending, but only its stack knows how much data did not reach TCP), but there will be difficulties with proxies and nat.
If about the gps tracker, then I did it on UDP. You accumulate a track, and when the data is to the eyeballs for MTU (there are nuances here, but they can be ignored for the tracker), you send it to the server. The server is silent until it notices a hole in the track (or once in n packets or m minutes) it makes a request to repeat the interval / s. The client clears the send data and clears the track up to the first requested interval (actually it's an ACK).
If you need to reduce the lag (for example, the tracker is watched online), then the server asks the tracker to reduce the “MTU” by x seconds (in fact, this can be a field in the forwarding request). On the tracker, write in the track information about the turned off tracker. The track is stored in a file used as a tape drive, so no fseek except backtracking to the beginning of the file.
From a non-programming, but from a logical point of view, it seems to me that if we are talking about transmitting coordinates, then we can send the current and a couple of previous ones in the package. Thus, triple redundancy from errors will be achieved and no additional protocols will need to be created.
Sorry if I'm wrong, better explain where I'm wrong.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question