0

I am testing my program on localhost and when i want to send from client to server file for example jpg and i want to split data to 100byte fragments with my header after my 548. fragment something get wrong like this. Server prints what is receive.

RECEIVED: 43749 | 1 | 546 | 1176 | jpg
RECEIVED: 60251 | 1 | 547 | 1176 | jpg
RECEIVED: 53346 | 1 | 548 | 1176 | jpg
RECEIVED: 55018 | 1 | 737 | 1176 | jpg

first is checksum second number of message third number of fragment fourth maximum of fragments and last file type. to this point everything is sening correctly smaller files also. What can be wrong any ideas please?

user3396072
  • 11
  • 1
  • 5

1 Answers1

1

I assume that you are referring to the "invalid" order of messages (737 comes after 548) ?

That is actually completely normal, as UDP does not guarantee the message (datagram) order:

Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.

Just use TCP instead, or implement an application level algorithm to buffer and reassemble your data as appropriate.

Also, note what UDP RFC (https://www.rfc-editor.org/rfc/rfc768) says:

The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP)

i.e. you may also face missing or duplicate datagrams (though this is more rare, unless you have some networking issues)

Community
  • 1
  • 1
zeppelin
  • 8,947
  • 2
  • 24
  • 30
  • 1
    Actually, it can, the specification does not say anything on any additional guarantees for the "localhost", so depending on the implementation of your OS network stack, and the type of machine you are running (e.g. multi-core or multi-CPU), you still might be getting datagrams out of order. see http://stackoverflow.com/questions/2533873/why-do-i-get-udp-datagrams-out-of-order-even-with-processes-runnning-locally or even loose some of them http://stackoverflow.com/questions/3034680/reliability-of-udp-on-localhost – zeppelin Oct 28 '16 at 18:12
  • 1
    Note this does not necessary mean that your problem is in the network stack, it might as well be an application level programming error, there are not enough details provided to say that for sure. But the thing is that you can not rely on UDP datagrams being delivered in particular order, or delivered at all, anyway. – zeppelin Oct 28 '16 at 18:18