На сервере мы делаем bind на 10001 и connect на 22375. На клиенте мы биндимся на 22375 и коннектимся на 10001.
И работаем на сокетах через send и recv - архитектурной разницы между клиентским и серверным сокетом нету кроме их зеркального отображения.

Remember that your socket must be "connected" in order to receive the ICMP errors. I've been told that Linux will return them on "unconnected" sockets, but I haven't verfied it. This may cause porting problems if your application isn't ready for it.

Since delivery of ICMP messages is not guarenteed you may not recieve this notification on the first transaction.

5.3 Does doing a connect() call affect the receive behaviourof the socket?

From Richard Stevens ( rstevens@noao.edu):

Yes, in two ways. First, only datagrams from your "connected peer" are returned. All others arriving at your port are not delivered to you.

But most importantly, a UDP socket must be connected to receive ICMP errors. Pp. 748-749 of "TCP/IP Illustrated, Volume 2" give all the gory details on why this is so.

5.4 How can I read ICMP errors from "connected" UDP sockets?

If the target machine discards the message because there is no process reading on the requested port number, it sends an ICMP message to your machine which will cause the next system call on the socket to return ECONNREFUSED. Since delivery of ICMP messages is not guarenteed you may not recieve this notification on the first transaction.

Remember that your socket must be "connected" in order to receive the ICMP errors. I've been told that Linux will return them on "unconnected" sockets, but I haven't verfied it. This may cause porting problems if your application isn't ready for it.

поведение этого костыля меняется от версии к версии ядра, не понятно вообще, как оно ведёт себя в 3-й версии, и уж тем более это сделает твою прогу непереносимой на другие платформы.

In later kernel versions, support for this option has been phased out: Linux 2.4 silently ignores it, and Linux 2.6 generates a kernel warning (printk()) if a program uses this option.

Почему их не отлавливает система, хотя она это делать обязана судя по мануалам?

Анализируя 64 бита, которые несет в себе ICMP-пакет, система знает - какому приложению послать сответствующее оповещение. Приложению....а не сокету.

Нет в UDP соединения, а потому нет и "connection reset by peer"

Тот в свою очередь при send получает код ошибки и говорит юзеру что connection reset by peer.

ICMP приходит отправляющей стороне как информирование о недоступности адресата, но ICMP не попадает на UDP'шный сокет, т.к. он не имеет к нему никакого отношения.

Если такой трафик пришел, то сокет должен эту тему отработать. По крайней мере для этого есть все предпосылки.

If, according to the information in the gateway's routing tables, the network specified in the internet destination field of a datagram is unreachable, e.g., the distance to the network is infinity, the gateway may send a destination unreachable message to the internet source host of the datagram. In addition, in some networks, the gateway may be able to determine if the internet destination host is unreachable. Gateways in these networks may send destination unreachable messages to the source host when the destination host is unreachable.

If, in the destination host, the IP module cannot deliver the datagram because the indicated protocol module or process port is not active, the destination host may send a destination unreachable message to the source host.

Another case is when a datagram must be fragmented to be forwarded by a gateway yet the Don't Fragment flag is on. In this case the gateway must discard the datagram and may return a destination unreachable message.

ну это совсем не показатель - их писали кто попало левой ногой. Потому эта вся аська и накрылась медным тазом

SO_BSDCOMPAT
Enable BSD bug-to-bug compatibility. This is used by the UDP protocol module in Linux 2.0
and 2.2. If enabled ICMP errors received for a UDP socket will not be passed to the user
program. In later kernel versions, support for this option has been phased out: Linux 2.4
silently ignores it, and Linux 2.6 generates a kernel warning (printk()) if a program uses
this option. Linux 2.0 also enabled BSD bug-to-bug compatibility options (random header
changing, skipping of the broadcast flag) for raw sockets with this option, but that was
removed in Linux 2.2.

но ICMP не попадает на UDP'шный сокет

асько-клиентах (в частности в Миранде)

снизу - ICMP датаграмма

Система об этом знает и сокеты должны реагировать

Идущий до маршрутизатора, который дальше его не переправляет, т.к. некуда, но никак не информирует отправляющую сторону, т.к. протокол не обязывает.

Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)