- Mon May 11, 2015 11:20 am
#17167
Your statement is simply not correct, and nobody experienced in the IP networking business would agree with your statement. For a given socket, once a local port is determined (either explicitly through bind(), or implicitly through the first outbound request,) that local port sticks to the socket until it is destroyed. And for a server socket, that is listening for incoming packets, clearly this has to be the case. (The currently released WiFiUDP class unbinds a server socket when you send a packet on it!)
If ports were not peresisttnt to a socket, then nobody could return traffic to a given socket. Network Address Translation, which is the main reason IPv4 still works despite there being more Internet-connected devices than IP addresses in the world, would break.
For more information on the basics of the TCP/IP stack (of which UDP is a part,) you might want to start with Stevenson's TCP/IP illustrated, and then perhaps continue with some important RFCs, such as RFC 2663 and RFC 4787. There are lots more, as well as lots and lots of good sample source code out there. Or just read the UNIX man page for the UDP protocol and the behavior of bind() and sendto().
Even the RFC you quote makes this clear -- if the port is changed, then return traffic will not be able to make it back to the sending node. And while the network has no session in UDP, the application layer does in almost all cases (except for fire-and-forget protocols like Syslog.)
For what it's worth, a recent update on HEAD of the WiFiUDP library retains the port across multiple send calls, but unfortunately uses the connect() call temporarily to do this, which has the side-effect of rejecting other incoming packets while formulating an outgoing packet. I have provided a more correct patch in a pull request.
That is not how it is supposed to work on ESP8266 or any computer for that matter. Outgoing packets can leave from any port.
Your statement is simply not correct, and nobody experienced in the IP networking business would agree with your statement. For a given socket, once a local port is determined (either explicitly through bind(), or implicitly through the first outbound request,) that local port sticks to the socket until it is destroyed. And for a server socket, that is listening for incoming packets, clearly this has to be the case. (The currently released WiFiUDP class unbinds a server socket when you send a packet on it!)
If ports were not peresisttnt to a socket, then nobody could return traffic to a given socket. Network Address Translation, which is the main reason IPv4 still works despite there being more Internet-connected devices than IP addresses in the world, would break.
For more information on the basics of the TCP/IP stack (of which UDP is a part,) you might want to start with Stevenson's TCP/IP illustrated, and then perhaps continue with some important RFCs, such as RFC 2663 and RFC 4787. There are lots more, as well as lots and lots of good sample source code out there. Or just read the UNIX man page for the UDP protocol and the behavior of bind() and sendto().
Even the RFC you quote makes this clear -- if the port is changed, then return traffic will not be able to make it back to the sending node. And while the network has no session in UDP, the application layer does in almost all cases (except for fire-and-forget protocols like Syslog.)
For what it's worth, a recent update on HEAD of the WiFiUDP library retains the port across multiple send calls, but unfortunately uses the connect() call temporarily to do this, which has the side-effect of rejecting other incoming packets while formulating an outgoing packet. I have provided a more correct patch in a pull request.
