Hello,

On 11/22/18 3:44 PM, Klebsch, Mario via Boost-users wrote:

...

Are there any recommendations on how to decide, whether the receive callback function should re-initiate a receive operation after a receive error or not?

Unlike TCP, UDP does not establish a connection. By default you will not receive any network errors on a UDP socket. You have to call connect() on the socket in order to receive (ICMP) error messages, but this has other implications.

I am getting receive errors without having called connect() before. Perhaps, this depends on the operation system. I observed this problem on windows 7. It seems that some errors reported by recvfrom() are not receive erros but send errors. Hence my problem, how to differentiate between these errors, since both are reported by recvfrom(). BTW. I do not use the UDP socket to talk to a single peer system, but I use a single UDP socket to talk to multiple different peers. This is my reason for not calling connect() on that socket. The application is prepared to peers not responding. In fact, the purpose of my code is to determine, whether a peer system responds or not. The description of recvfrom () in windows mentions, that WSAECONNRESET is signaled on an incoming ICMP Port Unreachable message. The linux man page tells, that ECONNREFUSED is returned when 'A remote host refused to allow the network connection (typically because it is not running the requested service).', which sounds to me like an ICMP Port Unreachable message. The MacOSX man page mentions ECONNRESET 'The connection is closed by the peer during a receive attempt on a socket.'. Are these the only errors returned my recvfrom(), that are related to earlier sendto() calls triggering ICMP responses? What about ICMP Destination Unreachable od ICMP Time Exceeded? My code is Windows/Linux/iOS, this is one of the reasons to use boost. 73, Mario