I haven't yet run up VMs to check to see if this behaviour is
different on pre Vista OSs.
Does anyone know if this behaviour is by design or if it's a winsock
bug?
Len Holgate
http://www.lenholgate.com/
> When an overlapped WSASendTo to results in a 'port unreachable' ICMP
> response from the remote host a pending WSARecvFrom on the socket that
> you sent the sendTo from will complete with 0 bytes read and an error
> of ERROR_PORT_UNREACHABLE. However, the WSARecvFrom "from address" is
> not set as I would expect it to be. The address portion is "correct"
> in that it is the address of the host that sent the ICMP port
> unreachable but the port is set to the local port rather than the
> "remote" port (i.e it's not set to the port that the SendTo was
> addressed to on the host that sent the ICMP message). Since the remote
> port is included in the ICMP message it seems strange (to me at least)
> that this information isn't used to fill in the port in the from
> address.
Are you sure that's not just junk that was left there from before? I
would expect that when you get an error, the output parameters are not
set at all and might just have whatever was in them before.
Does any documentation suggest that meaningful values are put in this
field if the operation returns an error? I personally find that quite
surprising.
DS
However, it would be very useful if the stack actually reported which
port was unreachable (since it knows!). If it isn't going to bother
then why fail an overlapped WSARecvFrom anyway?
On Dec 5, 4:41 pm, David Schwartz <dav...@webmaster.com> wrote:
> Well, it doesnt seem to be left over rubbish. I now clear the address
> to 0 before issuing any WSARecvFroms and I'm still seeing that the
> local address is filled in when the WSARecvFrom returns with
> ERROR_PORT_UNREACHABLE...
That's really odd. My guess would be that it does this for no
particular reason, maybe even by accident, and there's no rational
reason to check. If you get an error, there's no reason to expect the
fields to contain valid data.
Your other post brings up a good question -- why report the error? I
can think of no good reason to do so by default, since in most cases
there is nothing you can do with the information and it just wastes
time and cycles.
DS
True, but it just so happens that in this case I could do something
useful with it which is why I started investigating it...