He also said that the messages must be processed in the same order, and UDP does not guarentee that. To be done with UDP, you would need the application-layer protocol to check some ordering number in the message.
There are some other transport-layer protocols that might work, but TCP is probably good enough. The handshaking isn't much overhead for modern servers. The bottleneck for this application is likely the database, not the network connectivity.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
I'm curious ... Let's say, using UDP, message 1 comes in, then message 3, then message 5, and then message 2, and message 4 got dropped. How would you check ordering here? You process 1 immediately, but wait for a few messages to come in, then get message 2, process 2 and 3, and then ... when do you process 5? Or would you be proposing that with UDP, you would only process the messages that already came back in order, dropping all that were delayed out of order?
| [reply] |
There are many ways to do this. Some protocols treat UDP like AOL CDs--it doesn't matter if the post office forgets to to deliver the one you got today, because you'll get another one tommarow.
A good example protocol where it does matter is TFTP (RFC 1350) (which is very different from regular FTP). It solves it with a challenge-response mechanism. The sender sends packet 1, and the receiver acks it. Then the sender sends packet 2, and so on. If a packet is lost or comes out of order, the sender is expected to resend after a timeout.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |
The idea of UDP is that you implement whatever achitecture you want to deal with whatever your specific situation is (the U is for User :)
| [reply] |
In the past we have added a "sequenceid" to the header and dropped any packets that were out of sequence.
| [reply] |
the choice is not mine but actually in our case dropping a message is tolerable if the receving device does not answer in reasonable time. | [reply] |
Just for curiosity: in what kind of situations do you tolerate that messages can be lost?
| [reply] |
In our situation the devices are actually moving objects. They ask for their location. If I cannot send an answer in a timely manner I can as well drop the request or the response I am trying to forward. It has no value any more.
Besides, above my head sits and application that will resend its messages after about 1 minute if it did not get
a response earlier.
| [reply] |