UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port.
> ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.
You still have to get the packets though, and the OS had no idea about any application layer routing. If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports.
Edit: It's true I was playing a bit loose with the terminology (UDP is connectionless), but the behavior of packet routing and how changing the source port would mess with that is what I was getting at. If you want to be more correct, replace "connection" with "socket" in my original comment.
> UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing.
The filtering is completely optional to use.
> Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds.
That depends on how the requesting resolver has configured the socket.
> If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match.
That depends on how the requesting resolver has configured the socket.
> You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port.
Yes, obviously you have to know the application protocol you are trying to speak and how it uses UDP before you try to speak it.
> You still have to get the packets though, and the OS had no idea about any application layer routing.
Which is why application layer routing is called application layer routing.
> If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports.
No, you listen on local ports, not on remote ports.
> If you want to be more correct, replace "connection" with "socket" in my original comment.
Well, technically, some minor details would be more correct - but the fundamental assumption that you can only receive datagrams from one remote address/port with a given socket is just completely and utterly wrong, and not just in the sense that it's a theoretical possibility, but it's a perfectly normal use case. To take an obvious example, a common configuration for an OpenVPN server is to accept authenticated packets from any remote address and automatically switch to changing remote addresses for the sending direction, so when the client changes addresses, the OpenVPN session just keeps going.
As long as you don't connect() a datagram socket in the BSD sockets API, you will receive datagrams from any remote address (and you'll have to specify remote addresses using sendto() when transmitting).
It's seems the context of my original comment just went way over your head. Yes, obviously, if the protocol is defined to allow for varying the source port then yes it will work because you specifically write your program to handle that. But the person I was responding too was asking in the context of protocols like SSDP, which is not defined that way. And he was asking if you could vary the source port anyway even though the protocol doesn't support it, and I said no and explained why that wouldn't work.
> and I said no and explained why that wouldn't work.
And your explanation is at the very least misleading, bordering on wrong. Pretty much noone (except where the protocol spec explicitly were to require such behaviour, maybe) would implement a client that would open a socket per server/per request, but bind them all to the same local address/port.
Either you use one socket for all requests, in which case you don't connect(), so you receive all the responses, and thus would also receive datagrams from addresses/ports that you didn't send to, and instead you would do the matching of responses to requests in userspace, even if potentially based on the sender's address/port.
Or you use one socket per server/per request and let the OS assign you a free port per socket, in which case the local address/port is perfectly sufficient for the OS to route received datagrams to sockets. In the latter case, it's common to simplify your code by letting the OS handle the filtering of source addresses, but that's all it really is, filtering--actual routing based on remote addresses by the OS is not what normally happens and not why varying the response source port would not work with many protocols.
UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port.
> ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.
You still have to get the packets though, and the OS had no idea about any application layer routing. If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports.
Edit: It's true I was playing a bit loose with the terminology (UDP is connectionless), but the behavior of packet routing and how changing the source port would mess with that is what I was getting at. If you want to be more correct, replace "connection" with "socket" in my original comment.