UDP fails, sometimes

Using Arduino Networking, Protocols, and Devices
1

The code is hardly worth listing:

    udpipe->beginPacket(IPAddress(a,b,c,d),port);
    udpipe->write(buffer,PACKET_SIZE);
    udpipe->endPacket();

It seems like this works for some (NTP server) addresses but stalls during udp.write() for other addresses. I can't imagine how this could be. If it is due to the server I'm trying being offline (or incorrectly addressed: finger trouble is always possible), then how can one check whether there is a problem: there don't seem to be any useful return codes for these functions. I've got the sketch working fine at the moment using one NTP server but don't know whether it is just that I'm using a good luck.
Ideas anyone ?

2

I've got the sketch working fine at the moment using one NTP server but don't know whether it is just that I'm using a good luck.
Ideas anyone ?

Actually, UDP is counting on good luck. There is no way to determine if the UDP packet got to the destination unless the destination returns a packet to the sender.

edit: Just to add a little to that, a UDP packet could be lost for more than just one reason. Most fails are due to no device at that ip, or being rejected on the destination end by the firewall on that device. Routers may drop UDP packets if the router gets really busy and starts running out of TCP packet storage. Nothing is returned to the sender to indicate a fail in those conditions.

3

Thanks for the comment. I know about UDP not having 'assured delivery' but my problem is slightly different. And that is what is puzzling me. I've got code (not shown) to check for failure to receive a reply packet, but what seems to be happening is that the write itself stalls. I've put trace Serial.println() between each line and it seems like it never gets to the call to endPacket. Hence my confusion.

4

If the w5100 tx buffer fills up, it will stall in the write until the buffer has space. Could that be the problem?

The microSD card can cause problems if it is not either disabled or initialized.

edit: Is the computer you are trying to send UDP a localnet computer? Maybe it is not taking the packets, or not fast enough?

5

Thanks Tim, this is beginning to sound more interesting. The packet size is 48 bytes (standard for NTP request?) and so the buffer (32 bytes ??) could be full and the library code could well be trying to execute a write. The destination is one of the NTP servers, not sure which one because it is chosen on a round robin basis from a list of about 30. It could well be the problem arises because the server is offline (or mistyped in my list). But does the library really fail if it is given a bad IP address ? I could not find a way of checking that an address is correct before using it.
My code was modelled from example 15.14 in Arduino Cookbook, ISBN 978-1-449-31387-6, by the way.

6

The gateway device accepting the packet does not check if the destination ip exists, just if it can route to that ip subnet.

If the route to the destination has an intermediate device, like a router, the router will take the packet and send it on if it can. If it can't, it drops the packet.

If the route to the destination is directly to the device, like on a localnet, the w5100 may wait a while for the destination device to take the packet. I do not know what the timeout on that would be if the receiving device does not accept the packet or no device present. I have not checked.

7

Since it definitely is not on the local net (eg, 192.168.0.xxx) then it should go into the router. And the library should not hang. But it does seem that way to happen that way. Puzzling.

8

The router may take one packet, but it may not take any subsequent packets for the same ip until the next router takes that packet from it. Things could get clogged up fast. When things get clogged up, the first to go is UDP.

If you wish to guarantee a destination, may I recommend TCP instead of UDP.

9

The NTP servers use UDP, so TCP is not an option. However, it might help to increase the UDP buffer size to 48 bytes or more so that it doesn't have to send a second packet and then get stuck. I'll have a go the next time I'm reworking the code.

10

How often are you calling the NTP function?

edit: The NTP code in the ethernet examples waits only a second for a return packet from the NTP server. I have not experimented with what would happen if the packet arrives late (longer than a second).

11

Note that calling an NTP server very often is not always appreciated by the server, sometimes they even block IP addresses for a while.

wrote this some time ago - Arduino Playground - DS1307OfTheLogshieldByMeansOfNTP - you might have a look at the code to see diffs?