4 ms·
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
by DSMan195276 9y ago
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.
- zAy0LfpBZLC8mAC 9y ago> 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.