Go Down

Topic: Udp.beginPacket() time delay problem (Read 2 times) previous topic - next topic

SurferTim

Quote
If you mean how does it reach the correct IP/UDP address/port, it would require Network Address Translation (and perhaps UDP hole punching or explicit NAT configuration).

I figured you knew.  :)

Most routers use connection tracking internally for everything the Network Address Translator (NAT) does in that router. It matters not what protocol it used. It "links" the public ip/port to the Arduino private ip/port.

If the connection state never becomes established, which UDP never does, the NAT routing is dropped from the connection table after about 10 seconds on my routers. That is the time the NTP server has to get the response packet back to my router so it will know where to deliver it. After 10 seconds, the packet will be blocked by the firewall.

eddy9

Quote
If the destination device is on your localnet (same subnet), the source device will try to pass the packet directly to the destination device, but if it is not there to take it, the packet is dropped after a few seconds.


So, from what I understand from this discussion is that there is really no way around the delay in Udp.beginPacket() if there is no device to listen to it on the other end (without having to go in and modifying the library files). One thing though is that you would expect Udp.beginPacket() to return 0 if it fails to 'connect' to the receiving device but what I noticed is that it always returns 1. I can see the code in the library files where this is set but logically, shouldn't it return 0 if it fails to 'connect'?  The Arduino website documentation indicates that this function does not return which I guess is not correct.

PeterH


So, from what I understand from this discussion is that there is really no way around the delay in Udp.beginPacket() if there is no device to listen to it on the other end (without having to go in and modifying the library files).


Well, I suppose you could report an apparent bug to the people maintaining the library and wait until they fix it.
I only provide help via the forum - please do not contact me for private consultancy.

SurferTim

#13
Jan 06, 2013, 12:51 pm Last Edit: Jan 06, 2013, 02:54 pm by SurferTim Reason: 1
You are correct about the return values. The docs are in error. This is from Udp.h in the Arduino cores stuff:
Code: [Select]
 // Start building up a packet to send to the remote host specific in ip and port
 // Returns 1 if successful, 0 if there was a problem with the supplied IP address or port
 virtual int beginPacket(IPAddress ip, uint16_t port) =0;

 // Start building up a packet to send to the remote host specific in host and port
 // Returns 1 if successful, 0 if there was a problem resolving the hostname or port
 virtual int beginPacket(const char *host, uint16_t port) =0;

 // Finish off this packet and send it
 // Returns 1 if the packet was sent successfully, 0 if there was an error
 virtual int endPacket() =0;

beginPacket returns 1 if there is no problem with the ip or port format, 0 if there is a problem. But does not signify fail or success on the send.

endPacket returns 1 if the packet was sent successfully, or 0 if error.

beginPacket doesn't send anything, it just sets up the packet format. endPacket sends.

edit: The endPacket success return value does not indicate the packet got to its destination if the destination is not on your localnet, only whether the gateway router took it or not.

zoomkat

Quote
edit: The endPacket success return value does not indicate the packet got to its destination if the destination is not on your localnet, only whether the gateway router took it or not.


So this indicates a two way UDP communication with the router?
Consider the daffodil. And while you're doing that, I'll be over here, looking through your stuff.   8)

Go Up