Go Down

Topic: UDP fails, sometimes (Read 1 time) previous topic - next topic


The code is hardly worth listing:
Code: [Select]


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 ?


Nov 12, 2012, 01:21 pm Last Edit: Nov 12, 2012, 02:07 pm by SurferTim Reason: 1
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.


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.


Nov 14, 2012, 01:20 pm Last Edit: Nov 14, 2012, 01:23 pm by SurferTim Reason: 1
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?


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.

Go Up