Re: Ports and Protocols
From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: Fri, 19 Nov 2004 16:52:49 -0600
In article <firstname.lastname@example.org>, Craig A. Finseth wrote:
>>I also know that Windows will not...I repeat WILL NOT allow 2 different
>>processes to use the same port number, regardless of whether they use
>>different protocols or not.
>If you mean "listen on the same (IP, port) number pair," correct.
>Neither will Unix.
>Note that the (IP, port) pairs are separate for TCP and UDP stacks.
>So, I can readily have one application listening on port P for TCP and
>a different applicatoin listening on port P for UDP. Works just fine.
I'm not really sure how to interpret those two statements. But then,
I'm not using a branded UNIX. Certainly I can't run two processes on
the same port/protocol - I agree with that. But
[compton ~]$ /usr/sbin/lsof -i :21
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
inetd 256 root 4u inet 0x0179b414 0t0 TCP *:ftp (LISTEN)
nc 11638 root 3u inet 0x00948c0c 0t0 UDP *:21
That's quite obviously two separate processes - the first being the inetd
super server, and the second being netcat. From another computer, I have
no problem connecting to the FTP server, or to netcat (which is merely
set to dump packets to a terminal). I recall doing something similar with
both SunOS 4.1.3 and Solaris 2.5 with rshd on 513/tcp and syslogd on
513/udp - done on several hosts, though I'm no longer running either O/S.
For a windoze situation, I wonder if using a so-called personal firewall
to port forward (<mumble>/tcp to another port, <mumble>/udp to a different
port) maybe even on the same host would get around the apparent shortcoming.
>It is the _convention_ that, where both TCP and UDP versions of a
>given protocol are meaningful (e.g. DNS), to support both on the same
>numeric port value. But that is a convention and not a requirement.
Agreed. This is mentioned in passing in the IANA portnumber list.
>These are the essential differences, but it is quite common for a
>single application to use both. Each to its strength. For example,
>Telnet normally uses UDP for DNS lookups and TCP for its connection.
Not to pick to many nits, but telnet doesn't specifically do the DNS
lookups - it passes the lookup request to the kernel as a resolver call.
>Close, but not quite. If I do a DNS request on UDP, the server must
>respond using UDP: it can't decide to respond using TCP, regardless of
>the response size. As a client, if I think the response might be
>large (e.g., the UDP response was "too big to fit"), I might try a TCP
Depends on the application code as I understand it. The server does give
a UDP reply of up to 512 octets, but if the reply is longer, it gives
the first 512 octets AND sets the 'truncated' flag (next to last bit
in the third octet of the reply header). 'dig' can be set to ignore or
followup to that flag. The deprecated 'nslookup' did not ignore the flag
by default. 'host' reports the flag if set, but doesn't seem to have the
capability to make a TCP query. 'dnsquery' seems to be able to be forced
to use a TCP query, although UDP is default. The actual knob that gets
twisted to select UDP _or_ TCP queries is available as a library call.