This is a correct and expected behaviour. Please read some introduction to UDP. Wikipedia provides basic information on that matter: <https://en.wikipedia.org/wiki/User_Datagram_Protocol>.

UDP is connectionless (hence there is no such thing as "UDP connection"), fire-and-forget protocol. There is no way to tell if the data was delivered, if it was delivered uncorrupted and sendto can not detect such condition. If you require such functionality, use TCP or proper application-level protocol. However, if you require to know synchronously that a particular packet was not delivered, only application-level protocol will do, and it will be extremely slow (even way below 1kB/s).

It is possible to implement closed-port detection. If the remote machine cooperates and no devices on the route block it, one may receive ICMP type 3 code 3 packet. This is how network scanners and few other applications work. However, such solution is unsuitable for sendto as it requires wating for the mentioned packet. Also it may only detect errors: no-error conditions may be false positives.

Also the documentation for `socket_sendto` contains no information you have written about.

Well let's expand things a little. "fsockopen" has the note about UDP.

"UDP sockets will sometimes appear to have opened without an error, even if the remote host is unreachable. The error will only become apparent when you read or write data to/from the socket."

And let's expand things a little with ICMP. e.g. "closed-port detection" for the UDP socket type in a non-root environment, functioning on OS X.

Is that reasonable? It seems reasonable to me.

If it works in non-root environment then either binary has setuid flag set or the application is doing UDP ping, which requires only SOCK_DGRAM, not SOCK_RAW. But it is also not true ICMP ping. See man page for icmp(4) on MacOS X. mtr provides such functionality too (-u option or "u" key in curses mode).

As to `fsockopen`: the note is true. The function may not detect the condition, as it performs no communication with the remote machine. The error may become apparent only when you perform the communication: you'll not receive responses from the remote. _If_ the underlying sockets implementation is detecting ICMPs it _may_ give a warning. For example the Linux IP stack does this and you may sometimes receive 111 even with UDP. However, the errno is set only on the next write attempt and only if the ICMP packet is actually received (which implies it is ever sent by the remote). This is why you may receive warnings from `php_sockop_write` (main/streams/xp_socket.c). However it is using `send`, not `sendto`. As for `sendto`... I don't remember encountering 111 with it, so either it's not doing this, it's very rare for it to produce ECONNREFUSED or I have bad memory.

Anyway: PHP's `socket_sendto` is jut a plain wrapper around system `sendto`. It does nothing except translating arguments and then passing return value. See the source. Actually whole sockets extension is actually more or less a simple wrapper around POSIX sockets. Hence this bug report (or rather a feature request) belongs to various operating systems dev boards, not PHP.

The note about multiple sendto calls is interesting. I had some struggle with a subsequent recvfrom which may-or-may not be an artifact of that behavior.

The wording on fsockopen is a little more ambiguous perhaps than it should be: it sounds like the behavior for write is undefined (varies across OS).

I'd hoped I could use recvfrom; no luck there. Feel free to close this bug report.