brent timothy saner on 3 May 2014 20:02:01 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] udp ports

Hash: SHA1

On 05/03/2014 09:55 PM, Rich Freeman wrote:
> On Sat, May 3, 2014 at 9:50 PM, brent saner <>
> wrote:
> Multicast is a bit different.  With multicast (including the
> specific case of broadcast) my computer sends a single packet, and
> it goes to many other computers, with routers replicating traffic
> at each point along the way as needed.
> With unicast my computer has to send the same packet once for each 
> destination it is intended for.  You can still do that using a
> single source port for every computer on the internet, and even
> 64k destination ports on each of those.  It wouldn't make the
> network admins too happy though, assuming the NIC didn't melt.
> Rich

I should have clarified. Multicast UDP really should be used if you
expect a large number of connections on one destination, especially
with the lack of congestion control inherent in UDP. With multicast
implementations, you use one egress (source). I mean, this is all
assuming you're writing the software.

Straight UDP unicast RFC (RFC5405), however, DOES state:


UDP datagrams may be directly sent and received, without any
connection setup.  *Using the sockets API, applications can receive
packets from more than one IP source address on a single UDP socket.
[Some servers use this to exchange data with more than one remote host
through a  single UDP socket at the same time.]* Many applications
need to ensure that they receive packets from a particular source
address; these applications MUST implement corresponding checks at the
application layer or explicitly request that the operating system
filter the received packets.
(section 3.6, p16, 3rd paragraph. emphasis added.)

Further to note, RFC768's 'Format' and 'Fields' sections clearly
dictate that each datagram (optionally in IPv4 and required in IPv6)
include the source IP, **the source port**, the destination IP, and
the destination port. Since this is specified *per datagram*, you can
use multiple process on the same egress ephemeral port.

Of course, this is assuming that the datagrams on the same ephemeral
port are going to *different destinations*. If not, you're going to
see some potentially very strange things happening. (I would presume
it'd either look a lot like total dropped traffic for one application
using that port *or* mixed data going to one application and the other
half to the other- depending on how the UDP/IP stack prioritizes those
packets in the kernel. i.e. if they're balanced or if it's all given
to the lowest PID or what have you).

However, because I'm thorough to an annoying level, I tested this out

(nc = OpenBSD netcat version, not the GNU version, in case the
switches look wonky)

1.) on host "A":
$ nc -l -u 32780

2.) on host "B":
$ nc -u -p 32790 <HOST A IPADDR> 32780

3.) ALSO on host "B", using the same egress/source port:
$ nc -u -p 32790 <HOST A IPADDR> 32780

4.) And a netstat on host "B" confirms the same "ephemeral"
(philosophical question- is it still ephemeral if within the ephemeral
range but manually specified? hehe) ports used by *different processes*:

udp        0      0 <HOST B IPADDR1>:32790        <HOST A
IPADDR>:32780        ESTABLISHED 3422/nc
udp        0      0 <HOST B IPADDR1>:32790        <HOST A
IPADDR>:32780        ESTABLISHED 3312/nc


So all this to say no, you aren't running out of source ports if we're
talking strictly UDP.
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --