Go Down

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

PeterH

If the UDP implementation of connect is initiating a network connection then I would conclude that it is faulty. A UDP 'connect' should merely set a default destination address and should not initiate any network traffic. It seems to me that this is the sort of mistake that could easily have been introduced by using the TCP protocol implementation as the basis for a UDP implementation, and not addressing all of the differences.
I only provide help via the forum - please do not contact me for private consultancy.

SurferTim

Quote
A UDP 'connect' should merely set a default destination address and should not initiate any network traffic.

How do the NTP packets get to and from the NTP server with no network traffic? They are UDP. Or am I reading that wrong?

I do not believe there is a connection established between the source and destination devices like TCP. The packet is passed from router to router if they are operational, but that does generate network traffic, does it not?

PeterH


Quote
A UDP 'connect' should merely set a default destination address and should not initiate any network traffic.

How do the NTP packets get to and from the NTP server with no network traffic? They are UDP. Or am I reading that wrong?


UDP is a datagram protocol and TCP is a stream protocol.

With a stream protocol, a connection is established between a client and server by exchanging packets over the network and then content is written over the stream by exchanging additional packets. Hence there are distinct 'connect' and 'send' phases which both involve network traffic.

With a datagram protocol, no connection is established. Hence the 'connect' phase does not involve sending or receiving network traffic, it just updates the internal state of the client to indicate where subsequent datagrams will be sent to. Nothing is sent over the network until you actually send data. Since Udp.beginPacket() function does not have any arguments providing data to be sent, I would not expect that to cause any network activity.
I only provide help via the forum - please do not contact me for private consultancy.

SurferTim

OK. We are on the same page. You are correct. I don't know what would make the Arduino send to the w5100 stall for a few seconds. It seems it should take that packet and return. Unless maybe the next UDP packet send is stalled waiting for the previous one to finish or timeout?

BTW, I wasn't asking that question about NTP packets because I didn't know. Just wondered if you did.

For everyone else reading this, here is the "Question of the Day":
How do the NTP response packets from the NTP server on a public IP get through my router and firewall to my Arduino on a localnet IP?

PeterH

If you mean why is the incoming UDP packet allowed past the firewalls, the answer is that if it is then it's because the security policy permits it.

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 only provide help via the forum - please do not contact me for private consultancy.

Go Up