Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!lupine!djm
From: djm@lupine.UUCP (Dave Mackie)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ICMP_UNREACH_PORT
Summary: ICMP PORT UNREACHABLEs can be useful
Message-ID: <345@lupine.UUCP>
Date: 4 May 89 02:53:01 GMT
References: <8905021609.AA00846@lear.ultra.com>
Organization: Network Computing Devices
Lines: 44


	Well, you are a bit off-base on your description of the ICMP
	error logging mechanism. ICMP messages are logged (at least 
	in BSD) down in the IP/ICMP code itself. There is no network 
	error logger program that listens on a special port for ICMP 
	error messages.

	Also, the information contained in an ICMP Port Unreachable message
	is not useless. The problem is that (at least in BSD again) most 
	applications using UDP simply send their packets out using the 
	sendto() system call and use the parameters of that call to specify 
	the destination. That's great if your application is going to be
	sending packets all over creation and you only want to have the 
	overhead/complexity of a single socket. But that's not always the
	case for many applications. The problem with this approach is that the 
	poor networking code doesn't remember where you sent your packets,
	and therefore can't correlate any incoming ICMP port unreachable 
	messages with your application. So what generally happens is the
	application retransmits it's UDP packets for a while and then
	gives up. All the while the kernel is getting ICMP port unreachable's
	from the other host. This results in extra network traffic, and the 
	user waiting around for the !@#$ application to timeout.

	Now the solution to this situation is to have the application
	do a connect() to the destination. Yes, you can do a connect
	on a UDP socket. It just tells the networking code who you will
	be talking to with this socket, without generating any actual
	network traffic. Then the application can use send() instead of
	sendto(). When it attempts to reach a non-existent service on
	the destination host, it *does* get notification of the ICMP
	port unreachable message, and voila it can stop wasting everybody's
	time, and report the problem to the user. Now obviously this model
	doesn't work for every type of application, but it does for quite
	a few.

	In the case of TCP, the TCP spec gives the implementor a nastier
	more direct way of indicating displeasure about the destination
	port number. It sends a RESET back to the source machine. Now
	that should get it's attention!

						Dave Mackie
						Network Computing Devices
						djm@ncd.com